A scrum-inspired process for software product lines scoping

(1)

“A Scrum-inspired Process for Software Product Lines

Scoping”

By

Ivonei Freitas da Silva

Ph.D. Thesis

Federal University of Pernambuco posgraduacao@cin.ufpe.br

www.cin.ufpe.br/~posgraduacao

(2)

Federal University of Pernambuco

Center for Informatics

Graduate in Computer Science

Ivonei Freitas da Silva

“A Scrum-inspired Process for Software Product Lines

Scoping”

A Ph.D. Thesis presented to the Center for Informatics of Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Philosophy Doctor in Computer Science.

Advisor: Silvio Romero de Lemos Meira Co-Advisor: Eduardo Santana de Almeida

(3)

Catalogação na fonte

Bibliotecária Jane Souto Maior, CRB4-571

Silva, Ivonei Freitas da

A scrum-inspired process for software product lines scoping / Ivonei Freitas da Silva. - Recife: O Autor, 2013.

xix, 254 _{p., il., fig., tab.}

Orientador: Silvio Romero de Lemos Meira.

Tese (doutorado) - Universidade Federal de Pernambuco. CIn, Ciência da Computação, 2013.

Inclui referências e apêndice.

1. Engenharia de software. 2. Reuso de software. I. Meira, Silvio Romero de Lemos (orientador). II. Título.

(4)

Tese de Doutorado apresentada por Ivonei Freitas da Silva à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “A Scrum-inspired approach for the Software Product

Lines Scoping” orientada pelo Prof. Silvio Romero de Lemos Meira e co-orientada

pelo Prof. Eduardo Santana de Almeida e aprovada pela Banca Examinadora formada pelos professores:

__________________________________________ Prof. Alexandre Marcos Lins de Vasconcelos

Centro de Informática / UFPE

___________________________________________ Prof. Hermano Perrelli de Moura

___________________________________________ Prof. Vinicius Cardoso Garcia

___________________________________________ Profa. Rossana Maria de Castro Andrade

Departamento de Computação / UFC

____________________________________________ Prof. Adolfo Gustavo Serra Seca Neto

Departamento de Informática / UTFPR

Visto e permitida a impressão. Recife, 29 de outubro de 2013.

___________________________________________________

Profa. Edna Natividade da Silva Barros

Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.

(5)

Acknowledgements

This section is the last touch on a work that kept me busy five years of my life. Thus, I need to thank all those who have their role in the completion of this work.

I would also like to thank to my supervisor Prof. Dr. Silvio Meira for advices in his classes and for the opportunity in his research group, a software engineering ecosystem in Recife consequence of his work for about thirty years.

I would specially like to thank to my co-supervisor Prof. Dr. Eduardo Almeida for his valuable guidance, advice, encouragements throughout the thesis. It was a real pleasure and chance to work with him.

I would also like to thank to the RiSE group, for its cooperation and valuable contri-butions to this study.

I would like to thank several researchers, for their suggestions and valuable contribu-tions to this study. John McGregor, Charles Kruger, Frank Maurer, Klaus Schmid, Kyo Kang, David Weiss, Carolyn Seaman, Ivica Crnkovic, Silvia Abrahao, Emilio Insfran, Rafael Prikladniki, and Claudia Werner.

I would like to thank my examiners, Dr. Adolfo Neto, Dr. Alexandre Vasconcelos, Dr. Hermano Moura, Dr. Rossana Andrade, and Dr. Vinicius Cardoso for their time and relevant feedback.

This research has been funded by INES - Instituto Nacional de Ciência e Tecnolo-gia para Engenharia de Software and CNPq - Conselho Nacional de Desenvolvimento Científico e Tecnológico. I would like to thank them for the opportunity. To CIN-UFPE, Centro de Informática da Universidade Federal de Pernambuco, LES-UFBA, Laboratório de Engenharia de Software da Universidade Federal da Bahia, and all its members, I’m grateful for the supportive research environment over the past few years.

To my family Valdelice, Claudinei, Elenir, Valdemir, Cristiana, Victor, and Luana, your support began long before I ever undertook this journey. I have been very fortunate.

(6)

Mathematical physics presumes in the first place an electromagnetic field of activity pervading space and time.

The laws which condition this field are nothing else than the conditions observed by the general activity of the flux of the world, as it individualises itself in the events. The nature is thought as a structure of evolving processes. The reality is the process. —ALFRED NORTH WHITEHEAD (About process philosophy)

(7)

Resumo

A atividade de escopo em linhas de produto de software é o primeiro passo para identificar produtos, características e ativos de software em um segmento de mercado. As abor-dagens tradicionais para escopo de linhas de produto de software são processos densos e abrangentes em cenários com mudanças imprevisíveis e com poucos recursos. Um desafio chave nesse cenário é o gerenciamento sistemático da iteratividade, adaptabilidade e do feedback no processo de escopo de linhas de produto de software. Como último efeito, a indústria de software pode restringir investimentos no processo de escopo. Neste contexto, o framework Scrum, abordagem mais popular para incentivar a iteratividade, a adaptabilidade e o feedback, pode lidar com esse desafio. Estudos anteriores têm combinado Scrum com algumas atividades de linhas de produto de software obtendo bons resultados. Esta tese define um processo, denominado de RiPLE-ASC, para o escopo da linha de produtos de software inspirado nas práticas do Scrum. Este processo basea-se nas evidências da indústria (um estudo de caso real de escopo de linhas de produto usando uma abordagem tradicional), na opinião de especialistas em linhas de produto de software ágeis (através de um survey) e na literatura científica sobre linhas de produto de software ágeis (uma mapeamento sistemático). Um estudo de viabilidade e um estudo de caso “cross-case” executados com dois parceiros industriais de nosso grupo de pesquisa indicaram que o RiPLE-ASC tem aplicação prática e adequa-se em um ambiente de produção de software industrial bem como incentiva a iteratividade, adaptabilidade e o feedback detectando cedo características obsoletas e mudanças no domínio, requisitos, características e tecnologia.

(8)

Abstract

Scoping in Software Product Lines (SPL) is the first step to identify products, features, and assets in a market segment. Traditional approaches for SPL scoping are heavyweight and upfront processes in scenarios with unpredictable changes and little resources. An incurred key challenge is handling systematically the iterativeness, adaptability, and feedback in the SPL scoping process. As a final consequence, the software industry can hamper investment in the SPL scoping. In this context, the Scrum framework, as the most popular agile approach to foster the iterativeness, adaptability, and feedbacks, can address that challenge. Previous studies have combined Scrum into some SPL activities with good results. This thesis provides a process, named of RiPLE-SCA, for SPL scoping inspired in the Scrum practices. This process bases on industrial evidence (a case study of a traditional SPL scoping), expert opinion on agile SPL (through a survey), and scientific literature about agile SPL (a systematic mapping). A feasibility study and a cross-case study carried out with two industrial partners indicated that the RiPLE-SCA is practicable and appropriate for an industrial setting as well as fosters iterativeness, adaptability, and feedbacks detecting early obsolete features and changes in domain, requirements, features, and technology.

(9)

List of Figures

1.1 Thesis research design, adapted from (Spinola et al., 2008). . . 7

1.2 RiSE Labs projects . . . 11

1.3 Roadmap to the Thesis. . . 15

2.1 Two lifecycles for SPL - Domain and Application Engineering (Pohl et al., 2005). . . 19

2.2 Feature Model of a simple car (Apel and Kastner, 2009). . . 21

2.3 A product map of a mobile emergency notification application. . . 22

2.4 RiPLE (RiSE Product Line Engineering Process) . . . 23

2.5 Scrum framework (Larman and Vodde, 2008) . . . 30

3.1 Company feature model. . . 36

3.2 Case study general process. . . 38

3.3 Approach for data collection and analysis. . . 41

3.4 Scoping process timeline. . . 44

3.5 Causal loop diagram. . . 48

3.6 Specification of a feature. . . 55

3.7 Systematic Mapping Study Process, adapted from (Petersen et al., 2008). 70 3.8 Mapping Study Questions. . . 70

3.9 Search process workflow. . . 72

3.10 Filters of the selection process. . . 73

3.11 Agile Principles versus Research Types . . . 79

3.12 Contribution Type versus Agile Methods versus Research Type . . . 81

3.13 Contribution Type versus Practice Areas versus Agile Methods . . . 83

3.14 SPL Strategies versus Contribution Type. . . 85

3.15 Studies Distribution per Year . . . 86

3.16 Research design approach. . . 111

4.1 Iterative scoping pattern. . . 131

4.2 Adaptive scoping pattern. . . 132

4.3 Feedback scoping pattern. . . 133

4.4 Abstract relationship among the process elements. . . 134

4.5 Overview of the process. . . 135

4.6 Role - Scrum master . . . 136

(10)

4.8 Role - Domain expert . . . 137

4.9 Role - Inspector . . . 138

4.10 Role - Legacy systems engineer . . . 139

4.11 Role - Product expert . . . 140

4.12 Role - Scoping expert . . . 141

4.13 Role - SPL engineer . . . 143

5.1 Case study method adapted from (Yin, 2008). . . 160

5.2 Relationship among the small company products. . . 162

5.3 Relationship among the large company products. . . 163

5.4 Tracing on the case study research questions and collect procedure (inter-view and observation). . . 167

5.5 Tracing on the case study research questions and collect procedure (doc-umentation and focus group). . . 168

5.6 Causal loop diagram among the codes - small company. . . 175

5.7 Causal loop diagram among the codes - large company. . . 186

5.8 Consolidated flow causal diagram. . . 191

B.1 General scenario business goals (Clements and Bass, 2010) . . . 229

B.2 Document business goals (Clements and Bass, 2010) . . . 230

B.3 SPL goals (Schmid, 2002) . . . 231

B.4 Market strategies (Linden et al., 2007) . . . 232

B.5 Features specification . . . 233

B.6 Sprint backlog . . . 234

C.1 Background. . . 235

C.2 Background. . . 236

C.3 Feedback part one. . . 237

C.4 Feedback part two. . . 238

C.5 Feedback part three. . . 239

C.6 Feedback part four. . . 240

C.7 Feedback part five. . . 241

D.1 RescueMe SPL - business goals. . . 243

D.2 RescueMe SPL - market strategy. . . 244

D.3 RescueMe SPL - customer goals. . . 245

(11)

D.5 RescueMe SPL - partial product map. . . 247

D.6 RescueMe SPL - assessment criteria. . . 248

D.7 RescueMe SPL - scope backlog. . . 249

D.8 RescueMe SPL - sprint backog.. . . 250

D.9 RescueMe SPL - feature specification. . . 251

D.10 RescueMe SPL - features non-conformities report. . . 252

D.11 RescueMe SPL - partial feature model. . . 253

(12)

List of Tables

2.1 Agile values and principles - from Agile Manifesto (Beck and et. al., 2001) 28

3.1 List of analyzed documents. . . 40

3.2 Some metrics for the SPL scoping process.. . . 43

3.3 First generated code list. . . 47

3.4 Reviewed memos. . . 51

3.5 Effort data. . . 52

3.6 Feedback data. . . 53

3.7 Iterativeness and adaptability data. . . 53

3.8 Effort distribution for scoping process . . . 54

3.9 First iteration. . . 54

3.10 Second iteration. . . 55

3.11 Motivation data. . . 56

3.12 Requirements and technology volatility data. . . 57

3.13 Search Strings. . . 72

3.14 Research Type Facet (Wieringa et al., 2005). . . 75

3.15 Agile Manifesto Principles and Studies. . . 78

3.16 Number of Studies versus Agile Methods. . . 80

3.17 Number of Studies per Strategies. . . 85

3.18 Researchers in agile SPL . . . 94

3.19 Expert opinion on positive impact of the agile manifesto principles on SPL 96 3.20 Expert opinion on adapting the agile methods in SPL . . . 97

3.21 Expert opinion on practice areas possibly improved with agile principles. 99 3.22 Expert opinion on combining SPL strategies and agile approach . . . . 100

3.23 Expert opinion on organizational structure for agile SPL . . . 100

3.24 Expert opinion on insights and challenges identified through the System-atic Mapping on agile SPL and an Industrial Case Study. . . 103

3.25 Expert opinion on other approaches combining agile with SPL. . . 104

3.26 Case study, systematic mapping, and expert opinion survey weaknesses and strengths . . . 110

3.27 Summary of Findings. . . 113

3.28 Key findings - multi-method . . . 116

(13)

4.2 Develop product map description . . . 144

4.3 Prioritize major features description . . . 145

4.4 Define sub-features description . . . 147

4.5 Analyze commonality and variability description . . . 149

4.6 Process artifacts description . . . 153

5.3 RiPLE-ASC Iterativeness. . . 176

5.4 RiPLE-ASC Adaptability.. . . 177

5.5 RiPLE-ASC Feedback. . . 178

5.6 Impact of the RiPLE-ASC feedback, iterativeness, and adaptability. . . 180

5.9 RiPLE-ASC Iterativeness. . . 187

5.10 RiPLE-ASC Adaptability.. . . 188

5.11 RiPLE-ASC Feedback. . . 189

5.12 Impact of the RiPLE-ASC feedback, iterativeness, and adaptability. . . 190

A.1 Digital Databases. . . 225

A.2 Journals . . . 226

(14)

List of Acronyms

SPL Software Product Lines

ASD Agile Software Development

SM Systematic Mapping

SR Systematic Review

RiSE Reuse in Software Engineering (research group)

RiPLE RiSE Product Line Engineering

SEI Software Engineering Institute

SE Software Engineering

PuLSE Product Line Software Engineering

IID Iterative and Incremental Development

RUP Rational Unified Process

IT Information Technology

CESAR Centro de Estudos e Sistemas Avancados do Recife

CMMI Capability Maturity Model Integration

(15)

4.2.3 Fragments selection . . . 126 4.2.4 Fragments integration . . . 127 4.3 Method crossbreeding. . . 128 4.3.1 Contributes . . . 128 4.3.2 Replaces . . . 128 4.3.3 Extends . . . 129 4.3.4 Crossbred Process . . . 129 4.4 RiPLE-ASC Description . . . 130 4.4.1 Roles . . . 132 Scrum master . . . 133 Business expert . . . 134 Domain expert . . . 135 Inspector . . . 136

Legacy systems engineer . . . 137

Product expert . . . 138

Scoping expert . . . 139

SPL engineer . . . 140

Scrum team . . . 140

Scope owner . . . 140

4.4.2 Units of work: steps, tasks and activities. . . 140

Management actions (Scrum practices) . . . 151

4.4.3 Work products . . . 152

4.4.4 Computational support . . . 152

(19)

4.5.1 Context of study . . . 154 4.5.2 Results . . . 155 4.5.3 Discussion . . . 156 4.6 Chapter Summary . . . 158 5 Evaluation 159 5.1 Introduction . . . 159

5.2 Case Study Design . . . 159

5.2.1 Goal. . . 160

5.2.2 Research Questions (RQs) . . . 161

5.2.3 Case selection. . . 161

Small company participants . . . 163

Large company participants . . . 164

5.2.4 Data collection techniques . . . 165

Interviews. . . 165 Observations . . . 166 Documentation Analysis . . . 166 Focus Group . . . 166 5.2.5 Data Record . . . 166 5.2.6 Analysis procedure . . . 168 5.3 Results. . . 169 5.3.1 Small company . . . 169 Historic . . . 169

Codes, Clusters, and Memos of the evidence . . . 169

How do the stakeholders characterize the iterativeness of the process? . . . 174

How do the stakeholders characterize the adaptability of the process? . . . 174

How do the stakeholders characterize the feedback of the process?175 How do the stakeholders characterize the impact of iterativeness, feedback, and adaptability on the other variables? . . 176

5.3.2 Large company . . . 179

Historic . . . 179

Codes, Clusters, and Memos of the evidence . . . 181

How do the stakeholders characterize the iterativeness of the process? . . . 185

(20)

How do the stakeholders characterize the adaptability of the

process? . . . 186

How do the stakeholders characterize the feedback of the process?186 How do the stakeholders characterize the impact of iterativeness, feedback, and adaptability on the other variables? . . 187

5.4 Discussion: a cross-case analysis on a multiple case study . . . 188

5.4.1 How do the stakeholders characterize the iterativeness of the process?. . . 190

5.4.2 How do the stakeholders characterize the adaptability of the process?. . . 192

5.4.3 How do the stakeholders characterize the feedback of the process?193 5.4.4 How do the stakeholders characterize the impact of iterativeness, feedback, and adaptability on the performance of the process? . 194 5.5 Threats to Validity. . . 195

5.6 Validation of the Thesis Hypothesis and Research Questions . . . 196

5.7 Chapter Summary . . . 197

6 Conclusions 199 6.1 Summary . . . 199

6.1.1 Body of evidence on Agile SPL . . . 199

6.1.2 Development and evaluation of the process . . . 200

6.2 Future Work . . . 201

Bibliography 203 Appendices 223 A Systematic Mapping 225 A.1 Search Engines . . . 225

A.2 Journals and Conferences . . . 226

B Templates 229 B.1 Business goals. . . 229

B.2 Document business goals . . . 230

B.3 SPL goals . . . 231

B.4 Market strategies . . . 232

(21)

B.6 Sprint backlog . . . 234

C Evaluation Questionnaire 235 C.1 Case study - Background and Feedback . . . 235

D Feasibility and Observational Study - Rescueme 243 D.1 Business Goals . . . 243 D.2 Market Strategy . . . 244 D.3 Customer Goals . . . 245 D.4 SPL Goals . . . 246 D.5 Product Map. . . 247 D.6 Assessment Criteria . . . 248 D.7 Scope Backlog . . . 249 D.8 Sprint Backlog . . . 250 D.9 Feature Specification . . . 251

D.10 Features non-conformities Report . . . 252

D.11 Feature Model . . . 253

(22)

1

Introduction

Software Product Lines (SPL) enable software development to manage a set of similar systems through commonality and variability analysis (Clements and Northrop,2001; Pohl et al.,2005). Traditionally, SPL engineering aims a considerable upfront plan-ning and design with a heavyweight software process to achieve organization business goals. On the other hand, Agile Software Development (ASD) achieves the organization business goals through the practices, principles, and values focused on people and inter-actions, working software, customer collaboration, responding to change, and continuous improvement (Beck and et. al.,2001;Larman and Vodde,2008). Unlike SPL engineering, ASD aims a lightweight process and low upfront planning and design.

Nevertheless, both processes promote the same business goals such as reducing time to market, increasing productivity, gaining cost effectiveness and efficiency of software development efforts (Tian and Cooper, 2006). Furthermore, both processes assume that changes in requirements might occur and should be managed effectively (Tian and Cooper,2006).

The remainder of this chapter describes the focus of this thesis and starts by presenting its motivation in Section1.1and the definition of the problem, research questions, and the hypothesis in Section 1.2, Section 1.3, and Section 1.4 respectively. Then, the thesis goal is introduced in Section 1.5. To reach that goal, the followed research methodology is presented in Section 1.6. The overview of the proposed solution is introduced in Section1.7, while Section1.8describes some related aspects that are not directly addressed by this work. Section1.9presents the main contributions and, finally, Section1.10describes how this thesis is organized.

(23)

CHAPTER 1. INTRODUCTION

1.1 Motivation

An important and first step when establishing a SPL is to understand how the features (product functionalities and non-functionalities) can be organized in terms of SPL scoping.

SPL scoping “is the process of deciding in which parts of an organization products systematic reuse is economically useful and should thus be supported by a product line infrastructure” (John and Eisenbarth,2009). Scoping is the first step in the SPL engineering being performed before the SPL requirements engineering (Pohl et al.,2005). When performing a SPL scoping process, we should look for the most important features in the existing set of legacy systems (and new systems, if the features were provided) and structure them as common and variable features. It is also important to identify other related systems that might integrate the current scope to define trends and predict what the relevant markets will bear (Clements and Northrop,2001).

The commonality and variability analysis in SPL scoping is an important activity, because it must define and specify the common and variable features economically useful for a product line, with quality and high business value among the products of the line (Carbon et al., 2006). SPL scoping also aims an optimal (anticipated and complete) analysis of commonalities and variabilities, for the domain, products, and assets normally using a proactive, heavyweight, and upfront strategy. The SPL scoping processes assume that the domain should be stable, with formality in the planning, and a comprehensive process.

This proactive, heavyweight, and upfront strategy for the SPL scoping processes can be inappropriate for a scenario encompassing the information systems with unpre-dictable changes (that cannot be captured in advance), as well as, companies with little resources such as the stakeholders with short time available for the project and small teams to develop the project. Besides, it is common the refactoring in the SPL, because some requirements or product instances were not identified at the beginning of the SPL development (Linden et al.,2007).

Thus, considering that scenario, it makes little sense to waste an effort on a heavy-weight and upfront process, since it focuses on specifying all possible scoping features in an anticipated and complete way.

Moreover, the engineering and management of a SPL scoping, considering features, is still not well defined and clearly understood and this has hampered investment in, for example, scoping by the industry (John and Eisenbarth,2009).

(24)

1.2. PROBLEM STATEMENT

1.2 Problem Statement

As the traditional SPL scoping process (John and Eisenbarth,2009) requires a more disci-plined and planned management through the heavyweight and upfront nature, managerial problems can emerge for the previously mentioned scenario.

In this thesis, management problems regarding the feedback (that involves the com-munication and collaboration among the team members about the process and its results), iterativeness (that means the potential of the process to foster the scope building through several iterations in sequence, where each iteration is a self-contained mini-scoping process composed of tasks such as identify features), and adaptability (that means the potential of the process to foster adjustments in the artifacts, team, technology, and process to become more effective) were chosen to be investigated.

The feedback, iterativeness, and adaptability were chosen because (i) we observed them in an empirical study (Section 3.1), (ii) they are defined as key factors for the software development processes (Dybå,2000;Dybå and Dingsøyr,2008,2009;O’hEocha et al.,2010;Lindvall et al.,2002;da Silva et al.,2011), and (iii) the traditional processes did not provide systematic mechanisms to handle the short iterations, and foster the continuous feedbacks and adaptations in the SPL scoping process.

Moreover, feedback, iterativeness, and adaptability are also reported in other studies: • need of feedback between domain engineering and application engineering to minimize the degeneration and maximize the viability of the software product line (Carbon et al.,2008);

• SPL scoping is criticized for involving too much overhead, for instance, too much artifacts to describe the features, and being inflexible, for example, changes in the artifacts or tasks can be hard if the process does not provide mechanism to detect the changes, such as iterative cycles to foster the feedbacks and adaptations (Tourret,2006);

• in processes that analyze commonalities and variabilities for the SPL scoping, there is little attention to managerial aspects, such as lack of constant feedbacks between the teams. The processes do not provide a systematic and explicit way, such as short iterative cycles (Noor et al.,2006,2008);

• processes for analyzing commonalities and variabilities in SPL scoping may slow-down the feedback loops between teams (Ghanam et al.,2010);

(25)

• case study pointed out the need for a systematic and explicit mechanism of feedback loop at the technical level (Carbon et al.,2008); and

• SPL may become victims of their own success and start to suffer from a number of challenges, including high coordination cost, slow release cycles, and high system-level error density (Bosch and Bosch-Sijtsema,2011).

As a result of the lack of a systematic and explicit mechanism that fosters adaptations in the process and short iteration cycles, it may slowdown the feedback loops between teams. The lack of feedback loops and adaptations in the process can cause other problems such as prevent to detect changes in the domain.

Whether the changes in the domain, requirements, or technology are not detected in an anticipated way, more problems can emerge such as the unnecessary effort to perform the scoping on obsolete features that were useful, but became outdated.

1.3 Research Question

From those problems and motivation, a general research question that emerges is: how to manage commonality and variability analysis in SPL scoping with short iterations fostering feedback and adaptations to detect early changes and prevent obsolete features?

Based on this general question, the following specific sub-questions emerge as well: (RQ1) How to plan short iterations for the SPL scoping?, (RQ2) How to foster continuous feedbacks in contexts of short iteration for the SPL scoping?, and (RQ3) How to foster continuous adaptation in contexts of short iteration for the SPL scoping?.

These questions are a challenge because the current variability management processes for scoping (Khurum and Gorschek,2009;John and Eisenbarth,2009) rely on heavy-weight and upfront planning to predict and proactively handle variability in a system. Moreover, they do not address explicitly the aspects of short iteration, feedbacks, and adaptations as well as early detection of changes and prevention of obsolete features, mainly, in the mentioned scenario.

1.4 Hypothesis

Although SPL and ASD foster different strategies for software development and man-agement, SPL deals with many products for a domain in a way upfront whereas ASD

(26)

1.5. RESEARCH GOAL

deals with one product in a way incremental, a process to handle the commonality and variability analysis in SPL scoping with characteristics of agile management (short it-erations, feedbacks, and adaptations) stemmed from ASD can be an appropriate way to deal with the scenario where the change in the domain, customer requirements, and technology is very common (da Silva et al.,2011) (Diaz et al.,2011a) and little resources are available. In other words, a hypothesis is that ASD might foster, through a sys-tematic mechanism (agile method), short iterations, and continuous feedbacks and adaptations, when analyzing commonalities and variabilities during SPL scoping. As a result, a process with these characteristis can detect early changes and prevent obsolete features.

This hypothesis is viable, because ASD aims to provide good principles and practices that improve the feedback among the stakeholders and activities, increase iterativeness in the process, and foster adaptation of the process when necessary. As benefits, the effort might be reduced since changes have been detected early and obsolete features have been avoided, motivation might be increased, and the process might better handle issues regarding volatility (Dybå and Dingsøyr,2008). ASD fosters processes which are more reactive, lightweight, incremental, adaptive, and flexible. These qualities are inline with SPL scoping for the mentioned scenario, even though scoping deals with many products upfront.

1.5 Research Goal

This thesis addresses the problem of commonality and variability analysis management in SPL scoping. The focus is iterativeness, adaptability, and feedbacks regarding tasks, artifacts, and roles of the process. The goal is to define a process for commonality and variability analysis in SPL scoping that fosters systematically short iterations, and continuous feedbacks and adaptations in order to detect early changes and prevent obsolete features.

From this general goal, the following specific research goals are defined: (RG1) to define which SPL scoping tasks are necessary to analyze commonalities and variabilities, (RG2) to define which ASD method is necessary to systematically foster short iterations, and continuous feedbacks and adaptations, (RG3) to develop a process that integrates the chosen SPL scoping tasks and the ASD method, and (RG4) to systematically evaluate the proposed process, regarding iterativeness, adaptability, feedback, early changes, and obsolete features in the industrial scenarios.

(27)

Reaching the main research goal two direct results are smaller and more frequent iterations, and regular reflection and adaptation. These results can support another ones such as: early change detection and prevent obsolete features.

1.6 Research Methodology

This section describes the adopted research methodology in this thesis to achieve the proposed goals.

1.6.1 Research Philosophy

The research in this thesis is qualitative, interpretative, and exploratory. The research with these proprieties is interested in constructing knowledge in topics that need more evidence. The integration between ASD and SPL is a recent topic with few studies, mainly industrial empirical evaluations.

It is qualitative because we are interested in observing carefully the environment where the proposed process can be used, understanding the stakeholders perspectives when performing the process. Moreover, qualitative research is appropriate when few previous studies have been carried out and there is a process being studied (Patton,2001; Yin,2008).

It is interpretative because we are interested in understanding the perspectives, values, and several interpretations from the stakeholders when performing the proposed process (Klein and Myers, 1999). This research intends to consider the social context when describing, interpreting, and analyzing the social context where the stakeholders are inserted, thus, an industrial case study is adopted. Otherwise, positivism (Creswell,2009) would be adopted, however, it would be not feasible to operate the research in a controlled and managed laboratory setting.

Finally, it is exploratory because we are interested in describing the phenomenon (use of the proposed process) and providing insights of new theories, assumptions, or observations to understand the phenomenon (Yin,2008). Moreover, this is the case when few theories and assumptions have been done.

1.6.2 Research Design

The research design adopted the steps showed in Figure 1.1. Basically, during the conception phase, not only a secondary study is performed, but also a primary study. In

(28)

1.6. RESEARCH METHODOLOGY

Figure 1.1 Thesis research design, adapted from (Spinola et al.,2008).

addition, a synthesis based on these studies (primary and secondary) is performed. Thus, for the conception phase of the methodology, we performed a multi-method strategy to identify and synthesize the evidence and findings about the integration between ASD and SPL. First, in parallel, we performed an industrial case study about SPL scoping (Chapter3, Section3.1) to understand the bottlenecks of scoping in an industrial context and performed a systematic mapping study about the integration between ASD and SPL (Chapter3, Section3.2) to understand how the topic is organized and the possible gaps; next, we performed an expert opinion survey to ratify or refuse the evidence and insights previously identified (Chapter3, Section3.3); finally, we synthesized the evidence and findings (Chapter3, Section3.4) using some guidelines defined inWood et al.(1999). The proposed process is based on some identified evidence and findings of these studies. For the construction context, as the research design does not specify how many studies for feasibility study and observational study are necessary, we performed one study (for feasibility and observational contexts) in order to discuss whether the selected tasks (SPL scoping) and the ASD method provide useful results when working together and its practical application makes sense.

As useful results, the process should produce a commonality and variability analysis in terms of SPL scoping for other processes (architecture, implementation, testing) with a reasonable effort for the stakeholders. In summary, by useful results, we verify if the process fulfilled the overall goal for which it was created (Shull et al.,2001).

(29)

As practical application, the process steps should be effective and that the order in which they are executed should make sense. The process steps and their order should be similar to other traditional scoping processes, such as the mentioned in (John and Eisenbarth,2009).

The study refers to a SPL for emergency situation using mobile phone. We developed assets for some subdomains and observed the feedback, iterativeness, and adaptability during the SPL early stages.

For the evaluation context, we performed a multi-case study in industrial contexts (Runeson and Höst,2009), to verify if the proposed process fits into the SPL lifecycle and industrial settings, respectively. The evaluation observed the iteration among the tasks, the feedbacks among stakeholders, adaptation of the process, early detection of changes, and prevention of obsolete features.

We performed the studies in scenarios with legacy systems: (a) legacy systems that have available artifacts (for instance, documents, source code, and tools to detect similarities among the products) and (b) legacy systems without available artifacts (in this case, only the product execution is available). In both situations, the domain expert or developers were involved, although with limited availability, to define the commonality and variability analysis for the SPL scoping as well as unpredictable changes emerged and the team was small.

We adapted the proposed process for each scenario. For example, in a scenario one member performing two or three roles. Other example, names of roles have ever stablished in previous process of the company, then we adapted some role names for that scenario. Some proposed process activities were performed together in a company and separately in another one.

1.6.3 Meeting the Research Objectives

The conception phase addresses the objective RG1, through the systematic mapping, case study, survey, and synthesis of them. These studies provided the empirical base to reach the RG1.

The conception phase also addresses the objetive RG2 with the same studies. The studies are an initial body of knowledge about which agile principles and practices can be adopted when combining with SPL. In our case, agile management addresses the iteration size, and the amount of feedback and adaptation.

The conception and construction phases address the objective RG3. The studies (Chapter 3) provide useful evidence and insights for the building of the process. The

(30)

1.6. RESEARCH METHODOLOGY

construction phase develops and preliminarily evaluates the process in scenarios as that mentioned in this thesis.

The evaluation phase addresses the objetive RG4. It deals directly with the validation of the proposed process.

1.6.4 Research Validity

The main problem in qualitative research is its rigor. Thus, the important question is How to handle researcher bias? To mitigate the threats to reliability and validity of this research, we adopted some strategies (Creswell,2009).

Triangulation. We adopted the data source, researcher, and method triangulation when developing the initial body of knowledge on agile SPL (Chapter3). We adopted also triangulation when performing the studies, observational and case study. Basically, more than one technique (focus group, questionnaire, artifacts observations) to collect data from the study participants were applied. In addition, two researchers analyzed the set of evidence.

Respondent Checking. We adopted this checking in the case studies (3.1.1,4.5, and 5). The case studies participants confirmed or refused the findings after the researcher concluding the assumptions and analysis of the evidence.

Clarifying Researcher Bias. The main researcher of this study performed previous case studies in academic and industrial contexts during his doctoral research. He attended an empirical software engineering graduate course in computer science. Moreover, he has been exposed to state-of-the-art literature in SPL and ASD.

Transferability. The case studies are described in details. This thesis provides rich and thick descriptions with details of the study participants, setting of the scenario (context of the studies), and the object of study.

Prolonged engagement. The researcher was immerse during the case studies, ob-serving and collecting data. For the feasibility and observational study, the researcher was engaged with the participants in performing the proposed process, making decisions about what was salient and relevant to the purpose of the study.

Peer review. The research process of this thesis was checked externally by reviewers in conferences, journals and meetings with several researchers working with SPL, ASD, and empirical software engineering. The main concern was about the case study as a method for evaluation of the proposed process. The reviewers warned about the importance of performing the case study with quality.

(31)

1.6.5 Research Methodology Summary

The research methodology for recent topics in software engineering tends to interpretative, qualitative, and explorative strategies of the topic (Creswell,2009;Runeson and Höst, 2009). This tendency justifies itself because there are not assumptions, theories, or hypothesis enough to perform in a different way. This is the case in this thesis.

Although there are critics of this strategy for evaluation of research, it has increased its rigor and credibility through the techniques and actions that mitigated each issue aimed by the critics.

This thesis used these techniques and actions to improve the reliability and validity of the research, however, acknowledging that future studies will be necessary to increase the validity and reliability of the thesis.

1.7 Overview of the Proposed Solution

This thesis is included in the RiSE Labs context, whose goal is to develop a robust framework for software reuse (see Figure1.2).

RiSE Framework: The RiSE framework is a framework that involves the reuse processes (de Almeida et al.,2004), component certification (Alvaro et al.,2006), and reuse adoption processes (Garcia et al.,2007).

RiSE Tools: Research focused on software reuse tools, such as the Admire Environ-ment (Mascena et al.,2006), the Basic Asset Retrieval Tool (B.A.R.T) (Santos,2006), which was enhanced with folksonomy mechanisms (Vanderlei,2006), semantic layer (Durao,2008), facets (Mendes,2008), data mining (Martins et al.,2008), the Legacy InFormation retrieval Tool (LIFT) (dos Santos Brito et al.,2007), the Reuse Repository System (CORE) (Martins et al.,2008), and the Tool for Domain Analysis (ToolDAy) (Lisboa et al.,2011).

SOPLE: Development of a methodology for Software Product Lines based on ser-vices (Medeiros et al.,2010).

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 ( Caval-canti et al.,2008).

Exploratory Research: Investigates new research directions in software engineering and its impact on reuse;

(32)

1.7. OVERVIEW OF THE PROPOSED SOLUTION

Figure 1.2 RiSE Labs projects

CX-Ray: Focused on understanding the C.E.S.A.R. (Recife Center for Advanced Studies and Systems) and its processes and practices in software development.

RiPLE: Stands for RiSE Product Line Engineering Process and aims at developing a methodology for Software Product Lines, composed of scoping (Moraes,2010), require-ments engineering (Neiva et al.,2010), design (Dilorenzo et al.,2009;Cavalcanti et al., 2011a), implementation, test (Neto,2010;Machado,2010), and evolution management (Oliveira,2009). This thesis focuses on scoping (Moraes,2010) adjusting that process with Scrum practices.

The proposed process in this thesis consists of a set of units of work (activities, tasks, steps), guidelines, roles, and work products that enable the stakeholders involved with the SPL to perform the scoping process aligned with Scrum practices. Scrum was adopted because it is considered the mainstream within information IT circles and its practices wrap the scoping tasks handling in a systematic way the feedbacks, iterativeness, and adaptability.

The process aims to focus on building commonality and variability analysis for SPL scoping for existing similar products and/or new ones. This focus is due to the common scenarios found in the companies that develop similar software products in an independent way, as single-systems. However, these companies need and want to restructure their systems to obtain improvements regarding costs, quality, and productivity, which SPL and ASD processes can provide.

As the proposed process aims to foster iterativeness, adaptability, and feedbacks, it produces an incremental scoping representing the most important customers commonali-ties and variabilicommonali-ties in a domain, rather than a comprehensive set. The proposed process leaves room for further development work to meet requirements, architecture, and other SPL activities.

(33)

The process is in the RiPLE context being an alternative for the current process for SPL scoping.

1.8 Out of Scope

In the scoping process can exist many activities to identify, specify, and optimize sub-domains, assets, features, and products (John and Eisenbarth,2009). However, if we consider the legacy single-system context, normally the organization already knows what market it is in and it does not need to develop a business case. Moreover, the organization also knows the domain where its legacy products are operating. Thus, the following aspects are out of scope of the process.

• Domain scoping. As the process is focused on a scenario with legacy systems, formal and complete domain analysis can be unnecessary because the organization already knows the subdomains of the legacy products. Anyway, if necessary, the simple grouping of the legacy related features (a task in the proposed process) can generate the subdomains;

• Economical assessment. The thesis does not investigate formal economical as-sessment, then the proposed process does not perform it. Only market analysis is addressed to deal with marketing decisions;

• Asset scoping. The proposed process only look for features on artifacts of legacy products developed separately, in order to analyze the commonalities and variabili-ties. Asset scoping is particularly relevant when a new product line infrastructure is set up from scratch (Linden et al., 2007) and there is a measurement-based management, which is not common in scenarios that this thesis focuses on; • The proposed process does not focus on SPL adoption. There are other concerns

and activities (Bastos et al.,2011) that are out of scope of this thesis;

• Tool support. This thesis does not implement a tool for the process, although we needed to automate the tasks when the studies were performed;

• Clone detection. The proposed process does not include a step to verify whether similar systems code are clones. The clone detection performs similarity analysis. However, the business and domain experts ultimately must decide whether the similarities are commonalities or variabilities. Moreover, the computational effort 12

(34)

1.9. STATEMENT OF THE CONTRIBUTIONS

to perform the clone detection is high and there are few available tools (Duszynski et al.,2009). Thus, we decided to remove this step from the proposed process.

1.9 Statement of the Contributions

As a result of the work presented in this thesis, the following main contributions can be highlighted:

• A multi-method to synthesize evidence. An extensive and multi-method ap-proach (industrial case study, survey, systematic mapping) to synthesize the body of evidence in agile SPL.

• A process for SPL scoping integrated with Scrum practices. The proposed process addresses management aspects (iteration size, feedback, and adaptation) in order to be adopted in scenarios with unpredictable changes and small teams. • Empirical evaluations of the proposed process in industrial scenarios. This

thesis performed some studies to refine and evaluate the process. To refine it, academic studies through case studies were performed in order to verify whether the process tasks made sense. To evaluate it, a multi-industrial case study was performed to verify whether the process fits into industrial setting. In these studies, the iteration, feedback, and adaptation issues were analyzed qualitatively from the interviews, focus group meetings, and observations of the study participants. This thesis was partially shared with the scientific community based on the following contributions:

• I.F. da Silva. An agile approach for software product lines scoping. In Proceedings of the 16th International Software Product Line Conference - Volume 2 (SPLC ’12), Vol. 2. ACM, New York, NY, USA, 225-228.

• I. F. da Silva, P. A. da Mota Silveira Neto, E. S. de Almeida, and S. R. de Lemos Meira. Software Product Line Scoping and Requirements Engineering in a Small and Medium- sized Enterprise:An Industrial Case StudyJournal of Systems and Software, DOI: 10.1016/j.jss.2013.10.040, 189-206, 2013.

• I. F. da Silva, P. A. da Mota Silveira Neto, E. S. de Almeida, and S. R. de Lemos Meira. Empirical Findings in agile software product lines using a multi-method

(35)

approach to interpret the evidences. Information and Software Technology, Under evaluation.

• I. F. da Silva, P. A. da Mota Silveira Neto, P. O’Leary, E. S. de Almeida, and S. R. de Lemos Meira. Agile software product lines: a systematic mapping study. Software, Practice and Experience, 41(8):899-920, 2011.

• I. F. da Silva, T. Vale, E. S. de Almeida, and S. R. de Lemos Meira. Scrum-based approach for analyzing commonalities and variabilities in software product lines. In Proceedings of the 25th International Conference on Software Engineering and Knowledge Engineering (SEKE 2013), Boston, USA, 238-243.

• I. F. da Silva. Agile Software Product Lines. Invited Talk at the V Workshop of Fast Development of Applications (WDRA). X Brazilian Symposium of Software Quality (2011).

1.10 Structure of the Thesis

The remainder of this thesis is structured as outlined next. Chapter 2 presents relevant background information that introduces the context of the research, i.e., software product lines and agile approaches, respectively. Chapter 3 presents the body of evidence to justify the agile processes when performing SPL activities. Chapter 4 presents the detailed description of the proposed process. In this description are presented the roles, work products, tasks, steps, and workflow of the process. Also, a feasibility study is detailed to show that the process makes sense and provide useful results. Chapter 5 evaluates the proposed process through a cross-case study. Chapter 6 presents the conclusions and directions for future works.

Figure1.3shows the roadmap to the thesis. Although chapter 3 shows the reasons to combine agile with SPL, if the reader knows the concepts of agile and SPL, He/She can focus on chapter 4 and 5.

(36)

1.10. STRUCTURE OF THE THESIS

(37)

(38)

2

Foundations for the Process

This chapter presents the main concepts and principles of software product lines and agile software development. These concepts are the base for the proposed process.

2.1 Software Product Lines

2.1.1 Background and History

The SPL process has as background the mass customization and platform concepts (Pohl et al.,2005). Mass customization has been adopted in many moments of the science history. In the beginning of 12th century mass customization was adopted in Venice/Italy, to mass produce ships. That production was the largest industrial complex in Europe prior to the industrial revolution (Davis,2007). While that, Johannes Gutenberg published the first Bible using printing technology in the mid-fifteenth century (Martin, 1995). Moreover, in the beginning of 20th century, Henry Ford, the father of assembly-line automation, streamlined the production process. His company made a line of motor cars affordable, built quickly, and with high quality for that time (Bankston,2003;McGregor et al.,2002).

As the mass customization brings high investment to build individualized products, in particular, the car industry introduced the common platform concept. The platform provided a common structure of the main components for all cars, or set of cars. Thus, a reduction in the production cost was reached.

The systematic combination of the mass customization and platform concepts provides a strategy to build a common platform for reuse, as well as, with reuse when addressing customizations for a set of customers.

(39)

subrou-CHAPTER 2. FOUNDATIONS FOR THE PROCESS

tines, modules (1970’s), objects (1980’s), and components (1990’s) concepts (Griss, 1995). However, the reuse is ad-hoc yet. In other words, there is no institutionalized organizational process to produce software assets for reuse.

At the same time those concepts were emerging, three important milestones happened. In 1968, when Douglas Mcllory suggested that the software industry should be based on reusable components (Mcllroy,1968); in 1976, when David Parnas proposed the notion of program families (Parnas,1976); and in 1984, when James Neighbours proposed the concepts of domain and domain analysis (Neighbours,1984).

Nowadays, SPL has used the mass customization, platform, and reuse in a systematic way.

2.1.2 Main Concepts

Two definitions of SPL well accepted by its community are “SPL is a set of software intensive-systems sharing a common, managed set of features that satisfy 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) and “SPL is a paradigm to develop software applications (software-intensive systems and software products) using platforms and mass customization” (Pohl et al.,2005).

Independently of definition, the SPL processes consider two life-cycles, domain engineering and application engineering. Domain engineering is responsible for core asset development (also known as platform development). Requirements, design, code, and so on, are produced for reuse. Application engineering is responsible by products development. The core assets are reused (also known as derived, customized, and configured) and summed to the customer’s requirements for building a product. Figure2.1 shows the two software processes of the SPL.

Those two cycles are performed through one or more strategies commonly used in the literature to describe as the organizations deal with the investment in SPL. In (McGregor, 2008a) and (Frakes and Kang,2005), the proactive and reactive strategies are described. In a proactive way, the core assets are developed first and a high initial investment is necessary. In a reactive way, the core assets are developed incrementally based on products built as single-systems, the initial investment is low, however, the architecture must be robust and flexible to future product line needs. Besides these strategies, in (McGregor,2008a) it is described an incremental strategy which develops core assets in stages (increments), while planning from the beginning to develop a product line. In (Frakes and Kang,2005) and (Krueger,2002b) are mentioned the extractive strategy,

(40)

2.1. SOFTWARE PRODUCT LINES

Figure 2.1 Two lifecycles for SPL - Domain and Application Engineering (Pohl et al.,2005).

which reuses one or more legacy products (or subset of them) for the SPL initial baseline, then these core assets are evolved by any strategy.

As these are idealistic strategies, in practice there can be common a mix of them with some focus on one of them. For instance, the proposed process in this thesis is a mix of the extractive and incremental strategies. It is extractive in the first activity, when the stakeholders need to choose a subset of the assets to be structured as SPL, and incremental during the next ones, when releases are delivered.

Besides the two life-cycles and strategies, there are definitions that involve several concepts, practices, roles, activities, artifacts, and guidelines essential for building a SPL.

Feature is perhaps the most popular keyword when dealing with SPL. It can be defined as: (i) “a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems” (Kang et al.,1990), (ii) “a unit of functionality of a software system that satisfies a requirement, represents a design decision, and provides a potential configuration option” (Apel and Kastner,2009), and (iii) “a logical unit of

(41)

CHAPTER 2. FOUNDATIONS FOR THE PROCESS

behavior specified by a set of functional and non-functional requirements” (Bosch,2000). All these definitions are valid for this thesis, since we are interested in identifying the features from the legacy artifacts (as code, requirements, design, and user documentation) and new possible features from the business goals, customer requirements, and market needs.

Features can be named as commonalities, which means features that are present in all applications of the product line. In this case, the feature is mandatory for all products in the line. When the feature is not mandatory, it is optional, that is, it is not present in all applications of the product line.

Features can also be named as variation points (mandatory or optional), which are “a representation of a variability subject within domain artifacts enriched by contextual information.” (Pohl et al.,2005). Each variation point has variants (optional) defined as “a representation of a variability object within domain artefacts.” (Pohl et al.,2005). Features as optional, variation point, or variant are the main way to represent the variabilities among the software systems in the domains. The variabilities denote the features that are present or absent in the applications. They distinguish different applications of the product line (Pohl et al.,2005).

Variability can happen in the time and space. In time it is “the existence of different versions of an artifact that are valid at different times.” and in space it is “the existence of an artifact in different shapes at the same time.” (Pohl et al.,2005). In this thesis, we are interested in both variability kinds.

Variability can be internal and external from the customer view point. In the proposed process in this thesis, external variability is identified from the stakeholder needs (provided by domain experts), user documentation, systems in execution, and other artifacts with high level of abstraction. While internal variability is identified from legacy systems (low level of abstraction) such as code and artifacts of the system, refinements of external variability, and technical decisions. Both abstractions are refined in order to have the same granularity, that is, some external features can be specialized and some internal features can be generalized.

Features can also interact with each other. Feature interaction is described as excludes-constraintsor requires-constraints between features. The excludes-constraints between features means that both features cannot be present in the system at the same time. The requires-constraintsbetween features means that both features have to be present in the system at the same time (Classen et al.,2008).

Those previous concepts are represented in several artifacts produced in the SPL 20

(42)

engineering. Feature model is an artifact to represent the SPL features in a hierarchical way.

This hierarch produces relationships among the features. The relationship can be of father to son, that is, by specialization or aggregation of features.

When in a variation point, the variants can be aggregated (grouped) in a group of multiplicity, specifying how many variants should be selected.

The two common ways to represent the multiplicity are the “or” and “xor” (also known as “alternative”). In “or”, either one of the variants or both must be selected. In “xor”, exactly one of the variants must be selected and the other not selected (Haugen

et al.,2012). Figure2.2shows a typical feature model.

Figure 2.2 Feature Model of a simple car (Apel and Kastner,2009).

Moreover, feature model is an artifact resulting of an analysis of commonality and variability among the products of the line. According to (Weiss,1998), commonality analysis is the task of identifying common requirements for all family members (products in the line), whereas variability analysis is the task of defining how family members may vary.

Another artifact common when performing commonality and variability analysis is the product map. It is a matrix where the vertical axis shows the features of all products line and the horizontal axis shows the different products. When a feature is present in a specific product, then the cell (the intersection between the feature and product) is marked. This artifact can evolve with details such as metrics and asset evaluation values (Schmid,2002). Figure2.3shows a typical product map.

2.1.3 Defining scoping

SPL has several disciplines or practice areas (Clements and Northrop,2001) that trans-form step-by-step (as in a engineering process) customer features into system features. RiPLE process (see details in Figure2.4) represents a comprehensive process for SPL. It

(43)

Figure 2.3 A product map of a mobile emergency notification application.

encompasses several phases: scoping (Balbino et al.,2011), requirements (Neiva et al., 2010), design (Cavalcanti et al.,2011a) (Dilorenzo et al.,2009), implementation, testing (Neto,2010) (Machado,2010), evolution (Oliveira,2009), and risk management (Lobato, 2012). This thesis specializes a scoping process (Balbino et al.,2011) by integrating Scrum practices and simplifying some activities. Some RiPLE sub-processes have been applied in some industrial projects, but this aspect is out of the thesis scope.

If we compare SEI framework (Linda and et. al.,2007) with RiPLE, the former is more comprehensive because it addresses organizational and technical management beyond the common software engineering activities. However, RiPLE presents the process as a process with work product, roles, and tasks to be followed by the practitioners.

(44)

Figure 2.4 RiPLE (RiSE Product Line Engineering Process)

Scoping is the first activity when a new SPL is started. It is a process to decide what features should be present in the line in order to address economic benefits of software reuse. Scoping is also a continuous process that monitors developments in all relevant markets, application or technical domains and customer requests.

Scoping has its base in the areas of domain-specific reuse, economic modeling in reuse, marketing science and mainly in product line engineering (John and Eisenbarth, 2009).

2.1.4 Scoping processes

Scoping can be categorized by identifying and bounding capabilities (products and features) and areas (subdomains and assets). A generic scoping process considers several tasks such as identify products, identify features, identify subdomains, prioritize assets, prioritize features,and release planning (John and Eisenbarth,2009). Each one of these tasks is performed according to needs and specific scenarios. For instance, when the objective is only to structure the legacy single-systems, the identify subdomains task can be unnecessary, because stakeholders know their subdomains.

Secondary studies on scoping have been conducted to identify and characterize existing scoping processes (John and Eisenbarth,2009) (Khurum and Gorschek,2009).

A comprehensive process for scoping was defined by (Schmid,2002), which proposes activities for product portfolio scoping, domain scoping, and asset scoping. In particular, he defines the tasks: product line mapping, which gets an overview of the line and its features and their distribution in products; domain potential assessment, which identifies

(45)

domains with a high potential for reuse; and reuse infrastrucuture scoping, which plans the product line infrastructure. It is a process for scoping where analysis of commonalities and variabilities is performed by the first time.

To contextualize the proposed process in this thesis, the framework described in (Schmid,2002) was adopted. Basically, the framework organizes a taxonomy in four dimensions: object of scoping, goals of scoping, product, and process.

In object of scoping, products (software intensive-systems), domain, and assets (elements that should be made reusable) are defined. Proposed process in this thesis focuses on products, since thesis scenario is focused on the companies with legacy single systems. However, proposed process also considers domain, which defines specific tasks to identify features from the domain experts.

In goals of scoping, identification and description of a scope, assessment of the appropriateness of a scope, and optimization of a scope are defined. Proposed process in this thesis addresses all goals, when, respectively, defining tasks to identify features from the domain experts and legacy single systems, and prioritize major features to be delivered in releases.

In product, this thesis proposes a process that follows the most previous studies about scoping (John and Eisenbarth,2009;Balbino et al.,2011), providing feature model and product map work products.

In process, thesis process aims to deliver work products iteratively and incrementally. In proposed process, domain expert and scoping expert are main roles that produce feature model and product map when analyzing commonalities and variabilities in a domain. Other roles such as inspectors, SPL engineer, business experts, market expert, and developers are also roles who aid the domain and scoping experts when identifying, evaluating, and consolidating the work products.

Successful scoping must target right products for the domain, determined by factors such as knowledge of similar systems and future market demands, and it must have the appropriate scope, because too large or small scope will impair the capability of SPL to achieve variability and/or economies (Clements and Northrop,2001).

For this thesis, we can visualize feature model and product map artifacts as the first view of requirements organized hierarchically. This perspective is possible because we can understand features as high-level requirements, or, simply, requirements. Proposed process does not specify details (use case, formal specifications) for features, since it aims only to be a process for scoping, although requirements can be mapped in its work products. Moreover, influence of scoping activities and results for other development

A scrum-inspired process for software product lines scoping

“A Scrum-inspired Process for Software Product Lines

Scoping”

By

Ivonei Freitas da Silva

Ph.D. Thesis

Federal University of Pernambuco

Center for Informatics

Graduate in Computer Science

Ivonei Freitas da Silva

“A Scrum-inspired Process for Software Product Lines

Scoping”

Acknowledgements

Resumo

Abstract

List of Figures

List of Tables

List of Acronyms

Contents

1

Introduction

1.1

Motivation

1.2

Problem Statement

1.3

Research Question

1.4

Hypothesis

1.5

Research Goal

1.6

Research Methodology

1.6.1

Research Philosophy

1.6.2

Research Design

1.6.3

Meeting the Research Objectives

1.6.4

Research Validity

1.6.5

Research Methodology Summary

1.7

Overview of the Proposed Solution

1.8

Out of Scope

1.9

Statement of the Contributions

1.10

Structure of the Thesis

2

Foundations for the Process

2.1

Software Product Lines

2.1.1

Background and History

2.1.2

Main Concepts

2.1.3

Defining scoping

2.1.4

Scoping processes