Product Line Development - Seite 8/42 Strategy

Transcription

1 Controlling Software Product Line Evolution An infrastructure on top of configuration management Michalis Anastasopoulos

2 Outline Foundations Problem Statement Contribution Validation Seite 2/42

3 Foundations Product Line Engineering (PLE) is an approach that comes with true order-of-magnitude improvements - cost - schedule - quality PLE is based on strategic software reuse Seite 3/42

4 Focus of this work To control over time strategic software reuse in a product line Seite 4/42

5 When is this type of control necessary? Typically in bigger product line organizations in which reusable and specialized artifacts evolve in parallel Seite 5/42

6 High-level Product Line Development Process Development with reuse Seite 6/42 Development for reuse

7 Main Evolution Control Scenarios Controlling changes made on reusable assets (called core assets) Controlling changes made on product-specific assets (called instances) derived from core assets Controlling changes on product-specific assets that have been developed especially for a given product and are not the result of reusing core assets. Seite 7/42

8 What does evolution control actually mean? (1/2) Foundation: control theory Seite 8/42

9 What does evolution control actually mean? (1/2) Control loop in SPL evolution Change Request Change Seite 9/42

10 Configuration Management (1/2) Configuration Management (CM) is a mature and established discipline for managing the evolution of (single) systems Basic Functions of Configuration Management - Identification - Control - Status Accounting - Audit Seite 10/42

11 Configuration Management (2/2) In practice there are two main strategies addressing the PLE evolution control scenarios - Branching - Build Management Seite 11/42

12 Branching Example Main line of development Special line of development (e.g. Product A) Branch off Branch off Special line of development (e.g. Product B) Propagate Integrate back to mainline Propagate to other branches Seite 12/42

13 Build Management Example: Linux Kernel Build selected system Seite 13/42

14 Outline Foundations Problem Statement Contribution Validation Seite 14/42

15 Problem statement Configuration management is an established technology yet it does not directly address the PLE evolution scenarios The user has to combine many low-level operations for performing each of the evolution scenarios This can become a problem as the complexity of a product line grows Seite 15/42

16 Illustrative Example: Sample Product Line Seite 16/42

17 Illustrative Example: Sample Instantiations (white box) Seite 17/42

18 Illustrative Example: Sample Instantiations (black box) Product 1 Product 2 Seite 18/42 Product 3

19 Illustrative Example: Traceability given through CM Product 1 branch of S Product 1 branch of A Product 1 branch of B Seite 19/42

20 Illustrative Example: Complexity of CM Steps for finding out if something has changed in the instances of S. 1. Open the version graph of S 2. Identify the product branches (there may be many other temporary branches next to the product branches) 3. For each product branch look for new S versions since the last synchronization between family and Application Engineering 4. For each new version of S query the configuration management system for the changes made in that version 5. Filter out product-specific changes and identify changes that may affect S Seite 20/42

21 Outline Foundations Problem Statement Contribution Validation Seite 21/42

22 Contribution The 5 steps discussed above could be subsumed under a single logical command - findinstancechanges(s) This logical command would encapsulate and automate the underlying Configuration Management operations The contribution lies in the definition and realization of logical commands like the above that directly address PLE evolution control Seite 22/42

23 Layer on top of Configuration Management Seite 23/42

24 FE Processes (logical commands) to be supported Seite 24/42

25 AE Processes (logical commands) to be supported Seite 25/42

26 Sample implementation Seite 26/42

27 Outline Foundations Problem Statement Contribution Validation Seite 27/42

28 Current Validations Controlled Experiment Simulation Seite 28/42

29 Controlled Experiment Controlling SPL evolution Hypotheses H1: The proposed method significantly reduces the effort in terms of time necessary for performing evolution control operations - Framework Engineering - Application Engineering H2: The proposed method significantly increases the efficiency for controlling the evolution of a product line - repository complexity increase rate - correctness Seite 29/42

30 Setup Variables Variable Type Controlling SPL evolution Groups Family Engineering Application Engineering CL 2, 7, 9, 10 1, 6, 8, 13 SVN 3, 5, 11 4, 12, 14 The approach in use Independent Students experience Independent Necessary time Dependent Complexity increase Dependent Tasks Family Engineer Application Engineering Task 1 Create core assets Create instances Correctness Dependent Task 2 Change core assets Change instances Task 3 Find instances of core assets Task 4 Find changes in the instances Seite 30/42 Find the origins of instances (i.e. core assets they Amsterdam, have been derived from) Find changes in the origins

31 Results H1 28% improvement in average Seite 31/42

32 Results H2 H2 does not validate (only H2.2 validates) Seite 32/42

33 Analysis H2 H2.1 (complexity reduction) did not validate - false usage led to many unnecessary versions - however the CL gives by default more freedom and the probability of creating many unnecessary version is high H2.2 (correctness) did validate - CL users solved all tasks correctly - Only 20% of SVN users were correct Seite 33/42

34 Statistical Analysis of Experiment Results No statistical significance could be achieved - Not enough data points were available Statistical Tests performed thus far - t-test not applicable (chi-test negative, no normal distributions) - wilcoxon-test applicable but showed no significance - (pending) two-way analysis of variance suffering from limited number of data points Seite 34/42

35 Simulation Study Goal - to overcome the significance problems Approach - Gain more data points through simulation - Use the experiment data as a basis Seite 35/42

36 Simulation Model Seite 36/42

37 Simulation Results Simulation increased the observations to 289 from 32 19% improvement could be shown Statistical significance could be shown - Wilcoxon-test was applicable and successful Seite 37/42

38 Further results of simulation: Service time analysis 8% improvement Seite 38/42

39 Conclusions Controlling the evolution of Product Lines is difficult in current practice - CM used by default - yes traditional CM does not explicitly address the scenarios in PLE Solution approach is to encapsulate CM - explicitly address PLE scenarios - hide away the complexity - automate Initial Validations were positive - however the additional freedom given by the approach could also lead to problems Seite 39/42

40 Feedback Questions Controlling SPL evolution Have you seen this problem in practice? Do you see something missing from this research? Do you see formalization as a necessary ingredient? - what kind of formalization? Seite 40/42

41 Debate Questions Can processes solve evolution problems? - e.g. formal change processes Which field of Software Evolution research is missing currently sound empirical studies the most? What are proper ways of obtaining empirical validations of Software Evolution solutions? Seite 41/42

42 Thank you for your attention! Controlling SPL evolution Discussion, Questions, Feedback, Contact Information Michail Anastasopoulos: +49 (631) Fraunhofer IESE: Seite 42/42