http://labs.rise.com.br 1

DO MOREDO MOREw w w . r i s e . c o m . b rw w w . r i s e . c o m . b r

RiPLE-EM: A Process to RiPLE-EM: A Process to Manage Evolution in Manage Evolution in

Software Product LinesSoftware Product Lines

Thiago BurgosAdvisor: Silvio Romero de Lemos Meira

Co-Advisor: Eduardo Santana de Almeida

Informatics Center - Federal University of Pernambuco{thbo, srlm}@cin.ufpe.br, esa@rise.com.br

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study

– Definition, Planning, Analysis and Interpretation• Concluding Remarks

Outline

• Introduction

– Concepts, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study

– Definition, Planning, Analysis and Interpretation• Concluding Remarks

Introduction :: Concepts

• Software Reuse– Different Approaches– Software Product Lines

• Software Product Lines– Core Asset Development

(CAD)– Product Development (PD)– Management

• Evolution – Managing Changes– Building Assets and Products– Releasing Assets and ProductsSoftware Product Lines Essential Activities

(Clements and Northrop, 2002)

Introduction :: Context

• RiPLE-EM

– RiSE Product Line Engineering –

Evolution Management

Introduction :: Proposal Outline

• The goal of RiPLE-EM is to manage the evolution of assets and products in the software product line, by defining a systematic process composed by three main activities: Change Management, Build Management and Release Management, integrated in a macro-flow that guides all evolution management activities.

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study– Definition, Planning, Analysis and Interpretation

• Concluding Remarks

A Systematic Review

• Kitchenham (2004) guidelines• Questions calibration (Michalis’ feedback)

• Q. How evolution is being managed in SPL?SQ1. Do the approaches deal with SPL configuration identification? How?

SQ2. Do the approaches enable multi-level instantiation of assets? How?

SQ3. Do the approaches deal with SPL release management? How?

SQ4. Do the approaches deal with SPL change management?

SQ4.1. Do the approaches deal with variability evolution (adding, removing and changing)? How?SQ4.2. Do the approaches deal with assets change propagation between core asset and product development? How?

SQ5. Do the approaches deal with build management? How?

Systematic Review :: Criteria

• Inclusion Criteria– Approaches that offer any kind of support to SPL

evolution management– Best Practices and experiences reports

• Exclusion Criteria– Approaches that deal exclusively with Version Control

or Component-based development (CBD) specific issues

– Lack of detailed information about SPL evolution management

Systematic Review :: Primary Studies

• Selected Studies– KOBRA (Atkinson et al., 2000)– MOHAN AND RAMESH(Mohan et al., 2008)– NICTA (Staples, 2004)– PHONAK (Kurmann, 2006)– SEI's Technical Report (McGregor, 2007)– SRM (van der Hoek and Wolf, 2003)– TABORDA (Taborda, 2003)

Systematic Review :: Data Analysis

• SQ1. Do the approaches deal with SPL configuration identification? How?– No approaches addressing

configuration identification in the context of SPL were identified.

• SQ5. Do the approaches deal with build management? How?– No approaches addressing

build management in the context of SPL were identified.

• SQ2. Do the approaches enable multi-level instantiation of assets? How?– No approaches

addressing multi-level instantiation of assets in the context of SPL were identified.

Systematic Review :: Data Analysis

• SQ3. Release management

– Software Release Manager - SRM (van der Hoek and Wolf, 2003)

– Best Practices - PHONAK (Kurmann, 2006)

• Align platform and product releases• First release of new feature with one product• Releasing source code rather than binaries

– Best Practices - NICTA (Staples, 2004)

• Different product release constraints

– Release Matrix (Taborda, 2003)

• Focus on release planning, by creating a release matrix for each product.

Systematic Review :: Data Analysis

• SQ4. Change Management

– SPL Change Patterns identification (Mohan and Ramesh, 2006)

– Experience Report – NICTA (Staples, 2004)

• Changes to PLA Core Asset Variation Point and SPL Decay

– SEI technical report (Mc-Gregor, 2003)

• SQ4.1. Variability Evolution

– No approaches addressing variability evolution in the context of SPL were identified.

• SQ4.2. Change Propagation

– Kobra Approach (Atkinson et al., 2002)

• Feed-forward, Feed-back change integration

Systematic Review :: Questions Summary

• Some evolution areas are not explored yet in the context of software product lines.

• The main focus of the existing work is on Change Management, Release Management and Change Propagation.

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study– Definition, Planning, Analysis and Interpretation

• Concluding Remarks

RiPLE-EM :: Overview

• 2 Flows– Core Assets Flow– Product Flow

• 3 Disciplines– Change Management– Build Management– Release Management

RiPLE-EM :: Usage Example

RiPLE-EM :: Overview

RiPLE-EM :: CADxPD Communication

• The Propagation Request (PR) is a way to propagate the evolution (changes made to an asset or product) of a certain asset or product to another asset or product.

• It is managed by the change control tool used.

RiPLE-EM :: Roles

• Build and Release Engineer– Is the role responsible for building and releasing

products and core assets.

• CCB – Change Control Board– The CCB is the group (or individual) responsible for the

analysis and approval of both change and propagation requests. The group composition is flexible and depending on the change or propagation being requested the CCB can have different members.

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study– Definition, Planning, Analysis and Interpretation

• Concluding Remarks

RiPLE-EM CAD :: Macro Flow

RiPLE-EM CAD :: Release Planning

• This activitiy is performed in parallel with the development, and it can be refined until the release execution moment

RiPLE-EM CAD :: Macro Flow

RiPLE-EM CAD :: Change Management

RiPLE-EM CAD :: Macro Flow

RiPLE-EM CAD :: Build Management

RiPLE-EM CAD :: Macro Flow

RiPLE-EM CAD :: Release Execution

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study– Definition, Planning, Analysis and Interpretation

• Concluding Remarks

RiPLE-EM PD :: Macro Flow

RiPLE-EM PD :: Release Planning

• This activitiy is performedin parallel with the development, and it can be refined until the release execution moment

RiPLE-EM PD :: Macro Flow

RiPLE-EM PD :: Change Management

RiPLE-EM PD :: Macro Flow

RiPLE-EM PD :: Build Management

RiPLE-EM PD :: Macro Flow

RiPLE-EM PD :: Release Execution

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study

– Definition, Planning, Analysis and Interpretation

• Concluding Remarks

The Experimental Study :: Definition

• Wohlin Guidelines (Wohlin et al., 2000)

• GQM (Basili et al., 1994)

Goal Summary

Analyze the RiPLE-EM processfor the purpose of evaluation

with respect to understandability, usability, completeness, applicability and effectiveness

from the point of view of SPL researchers and practionersin the context of a software product line project.

The Experimental Study :: GQM

QuestionsQ1. How much effort does it

take to apply the process?

Q2. Do the subjects have difficulties to understand/apply the process?

Q3. Are the subjects satisfied in using the process?

Q4. Is there any missing activity, roles or artifact?

Q5. How many propagation requests were uncompleted?

MetricsM1. Effort to Apply the Process

(EAP)

M2. Process Understanding and Application Difficulties (PUAD)

M3. Subjects Satisfaction (SS)

M4. Activities, Roles and Artifacts Missing (ARAM)

M5. Uncompleted Propagation Requests (UPR)

The Experimental Study :: Planning

• No well-known value for the metrics– Values chosen based on practical experience and internal discussions

• Null Hypothesis– H01: µEAP ≥ 20%

• Effort to Apply the Process (EAP)

– H02: µPUAD ≥ 40%• Process Understanding and Application Difficulties (PUAD)

– H03: µARAA > 3 • Actvities, Roles and Artifacts Missing (ARAM)

– H04: µUPR > 20%• Uncompleted Propagation Requests (UPR)

The Experimental Study :: Operation

• Execution– Training: from August to October in 2008– Execution: from October to December in 2008– 7 M.Sc. students and 2 Ph. D. students– Rental Domain

• Library, Car rental, Movies Rental…

• Data Validation– Data from 4 students were removed, because they did

not participate of the whole study and/or they did not answer the questionnaire.

Analysis and Interpretation

• Q1. How much effort does it take to apply the process?

Analysis and Interpretation

Q2. Do the subjects have difficulties to understand/apply the process?

Analysis and Interpretation

• Q3. Are the subjects satisfied in using the process?– 40% Satisfied– 40% Impartial– 20% Unsatisfied

Analysis and Interpretation

• Q4. Is there any missing activity, roles or artifact?

– None of the subjects identified any missing activity, role or artifact.

• Q5. How many propagation requests were uncompleted?

– No propagation requests were raised in this project, and that rejects the null hypothesis.

The Experimental Study :: Lessons Learned

• Project Context– Time and product numbers constraints– Approximatively 69% of the project time was spent on the

SPL scoping, domain requirements engineering and domain design, leaving not much time to product development.

– The assets were not evolved due to time constraints.

The Experimental Study :: Lessons Learned [2]

• The results can NOT be generalized due to the experiment context.

• Possible Scenarios to replicate the experimental study– A SPL scenario where the core asset are being

changed/evolved– A SPL scenario where several products are being

developed at the same time– Consequently, a scenario where changes need to be

propagated from one development level to another one.

Outline

• Introduction

– Motivation, Context and Proposed Solution

• The Systematic Literature Review

– Planning, Conduction and Reporting

• RiPLE-EM

– RiPLE-EM for Core Asset Development

– RiPLE-EM for Product Development

• The Experimental Study

– Definition, Planning, Analysis and Interpretation

• Concluding Remarks

Concluding Remarks

• Contributions– A systematic Review on Evolution Management approaches

for SPL, The RiPLE-EM Process definition, An experimental study on RiPLE-EM

• Ongoing Work– Systematic Review and RiPLE-EM process

experimentation publication.

• Published Work– Michail Anastasopoulos, Thiago Henrique Burgos de Oliveira,

Dirk Muthig, Eduardo Santana Almeida , Silvio Romero de Lemos Meira. “Evolving a Software Product Line Reuse Infrastructure: A Configuration Management Solution”, in the Third International Workshop on Variability Modelling of Software-Intensive Systems, Seville, Spain, 2009.

Concluding Remarks :: Future Work

• Version Control– Version Control and Continuous Integration– Relationship between Product Line

Architectures and Repository Structures• Change Management

– Change Guidelines for typical SPL artifacts– Variability Evolution

• Agile– RiPLE-EM agile, following agile principles.

• Experiment Replication– Replication of RiPLE-EM experiment in an

industrial context

QuestionsQuestions??

RiPLE-EM: A Process to RiPLE-EM: A Process to Manage Evolution in Manage Evolution in

Software Product LinesSoftware Product Lines

Thiago BurgosAdvisor: Silvio Romero de Lemos Meira

Co-Advisor: Eduardo Santana de Almeida

Informatics Center - Federal University of Pernambuco{thbo, srlm}@cin.ufpe.br, esa@rise.com.br