Software maintenance and evolution Evolution and maintenance of software product lines

1. Software maintenanceandevolutionEvolution and maintenance of software product lines Prof. Robertas Damaševičius,robertas.damasevicius@ktu.lt Prof. Vytautas Štuikys Kaunas University of Technology Evolution and maintenance of software product lines

2. Contents • What is software product line (PL)? • PL development • PL evolution • PL evolution driving forces • Porter’sFiveForcesModel • PL maintenance • Guidelines for PL evolution and maintenance Evolution and maintenance of software product lines 2

3. Definitions • Software Product Line (PL): a collection of similar software systems created from a shared set of software assets using a common means of production • Product Line asset: any kind of asset that captures information about PL and its development process • Core asset: a reusable artifact or resource that is used in the production of more than one product in a software PL • an architecture, a software component, a domain model, a requirements statement or specification, a document, a plan, a test case, a process description, or any other useful element of a software production process • Product Line evolution: accumulated PL change over time Evolution and maintenance of software product lines 3

4. Variability • Ability of a system to be efficiently extended, changed, customized or configured for use in a particular context. • Ability of a system, an asset, or a development environment to support the production of a set of artifacts that differ from each other in a preplanned fashion • Ability of a core asset to adapt to usages in the different product contexts that are within the product line scope. • When a core asset is created, the common part is produced, which will not change as the core asset is used from product to product. • A variable part is the position in an asset where a variation can took place • The realization of a variable part is called a variant. Evolution and maintenance of software product lines

5. Product line • "A software product line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way" (Clements & Northrop, 2001) Evolution and maintenance of software product lines 5

6. Product line • Companies today do not develop individual products, rather, they develop product lines - families of manufactured products, that need to be customized for a variety of physical devices, protocols, environments, and languages • To cover product line, companies need to use components from multiple suppliers, who offer feature-specific services • This leads to a product line with alternative components • Product line becomes a first-order entity of development Source: www.biglever.com

7. Motivation for product lines • Suppose a software system S evolves into a family (“line”) of similar systems released to various customers over time • 1. Each system release may implement: • a. Common features shared by all releases of S. • b. Variant features shared with some other releases • c. Some unique features • 2. Feature implementation may vary across system releases. • 3. Each release should contain only features that its customers wish to have. This may be important for: • a. Reliability reasons • b. Strict time performance or memory consumption requirements, for example, in embedded system software, mobile device applications, etc. • c. Large packages such as that need to be tailored for different operating environments Evolution and maintenance of software product lines 7

8. Contents • What is software product line (PL)? • PL development • PL evolution • Porter’sFiveForcesModel • PL maintenance • Guidelines for PL evolution and maintenance Evolution and maintenance of software product lines 8

9. PL engineering • Software PL engineering allows the shifting of the focus of development and evolution from the individual products to the PL Evolution and maintenance of software product lines

10. Reusable PL assets • Normal software components • Training specific to product line • Business case for the use of a product line for a set of products, • Set of identified risks for building products for product line, • Etc. Evolution and maintenance of software product lines 10

11. PL development (1) Sami OUALI, Naoufel KRAIEM, Henda BEN GHEZALA. Framework for Evolving Software Product Line. International Journal of Software Engineering & Applications (IJSEA), Vol.2, No.2, April 2011 Evolution and maintenance of software product lines

12. PL development (2) • In software product line development context, the purpose is to develop not only a single product but several more or less distinct products • These products are developed together. • Information captured in the development artifacts concerns all the product of the software product line and not only each product separately. Evolution and maintenance of software product lines

13. Reuse in PL (1) • Let A be an artifact and A' be the same artifact after modification, A' = modify (A). • Let another artifact B be an exact copy of A, denoted by B = copy (A). • Let C denote a core asset and let P denote an artifact of a product. • (a) P = modify (copy (C)) • This is the case where a core asset is acquired by the product and is then modified to produce a specific artifact. It is a classical scenario of reusing a core asset as a baseline for a specific artifact. • Example: C is a design pattern and P is a specific design based on the pattern • (b) P = copy (modify (C)) • This is the case where a core asset is modified before being acquired by the product. This scenario usually occurs when several products require a modified version of the core asset at the same time. • Example: component engineering group develops a specific design pattern and then copies of that pattern are released for acquisition. Evolution and maintenan ce of software product lines

14. Reuse in PL (2) • (c) C = modify (copy (P)) • This is the case where a specific product’s artifact is mined but needs to undergo modifications before becoming a core asset. • Example: establishing an initial core assets repository from specific existing products, consistent with a standard architecture. • (d) C = copy (modify (P)) • This is the case where a specific product’s artifact undergoes modifications before being mined as a core asset. This is the least likely scenario for reuse, because the core assets plane is not expected to “record” modifications performed within specific products. • Example: component engineering group notices that the product has upgraded an artifact which was previously mined as a core asset. Evolution and maintenan ce of software product lines

15. Contents • What is software product line (PL)? • PL development • PL evolution • Porter’sFiveForcesModel • PL maintenance • Guidelines for PL evolution and maintenance Evolution and maintenance of software product lines 15

16. Software evolution • Evolution is the accumulated effects of change over time • Forces drive the change in a certain direction at a certain point in time, and whether those forces are anticipated or controlled is uncertain • Direction of that change may or may not be desirable • Evolution is a challenge for a product line organization • Complex relationships among those assets, and between those assets and the products they are part of, magnify the effects of evolution Evolution and maintenance of software product lines 16

17. Product line change • Product line assets change over time • in response to a specific stimulus such as the need to meet a new standard or to address an emerging market niche • effects of change can be anticipated and directed • assets are changed for reasons specific to the asset such as removing defects or achieving consistency with other assets • effects may not be recognized until changes have accumulated Evolution and maintenance of software product lines 17

18. Asset evolution • Asset evolution happens in response to forces both outside and within PL organization: • A new release of a standard, which is integral to the products, forces changes in core assets and directs evolution toward compliance with the standard • Such a release can be anticipated, its impact can be analyzed, and resulting changes can be managed • Adopting new technologies forces assets to change. • This may be part of a continuous evolution as a technology matures, or a radical change if a disruptive technology emerges and forces a major change in direction • A change in marketing strategy • Can be an internal evolutionary force that directs evolution toward higher performance or more features Evolution and maintenance of software product lines 18

19. Asset evolution problems • Asset evolution can cause problems with the core asset base and with product production • Certain dependencies among assets must be maintained • If two related assets evolve in different directions, the consistency of the core asset base is threatened • Conflicting goals can lead to conflicting changes that cause erosion of the core asset base’s integrity • To avoid such erosion, a change to any core asset must be analyzed in advance to determine its impact on related assets • An evolution plan is developed that balances the forces of potentially inconsistent changes Evolution and maintenance of software product lines 19

20. Phenotypic asset change • Not every change to an asset should be considered evolutionary • A phenotypic change typically affects a single product. • Defect repair does not move an asset in a specific direction; it simply moves the single asset to where it was assumed to be all along • When a supplier discontinues a component, selecting an exact replacement from a different company does not evolve the PL or individual products in any direction • It simply allows those products in the product line that use the component to maintain their current position Evolution and maintenance of software product lines 20

21. Software PL evolution problems • Evolution of a single asset can affect many other assets and multiple products • Many relationships exist among product line assets • Creating a product involves the use of many assets, some of which might be derivations of other assets • One asset might constrain the design or structure of another • Changes made to one asset are propagated to other assets Evolution and maintenance of software product lines 21

22. Anticipated vs. Unanticipated Evolution Evolution and maintenance of software product lines 22

23. Anticipated evolution • Three software product line practice areas are primary influences on the mitigation of anticipated evolution: • Technology Forecasting enhances the possibility that any evolution will be anticipated and proactively searches for changes related to advances in technologies used to implement the product line • Understanding Relevant Domains provides an understanding of which features are most likely to change • Market Analysis provides an understanding of which existing products will become obsolete and which new products are likely to be successful Evolution and maintenance of software product lines 23

24. Unanticipated evolution • External events to the product line organization lead to unanticipated evolution: • Political decisions made by organizational and technical managers lead to unpredictable changes and unanticipated evolution • Business cycles can be predicted, but the effects of their changes cannot always be • Technology cycles do not always run their course. In some cases, disruptive technologies gain rapid, widespread acceptance forcing unanticipated changes in products Evolution and maintenance of software product lines 24

25. Handling unforeseen (unanticipated) changes Evolution and maintenance of software product lines 25

26. Evolutionary Life Cycle of Product Line • All assets evolve, not just the software assets. • Dependencies among PL assets provide pathways for propagation of evolutionary forces (According to Svahnberg and Bosch) Evolution and maintenance of software product lines 26

27. Categories of PL Architecture Evolution • Split of the product line architecture • Derivation of a new PL architecture from an existing one • Development of new PL components • Change of PL components • Replacement of a PL component • Split of a PL component • New relationship between PL components • Changed relationship between PL components Evolution and maintenance of software product lines 27

28. PL configuration management and evolution model A Configuration Management Model for Software Product Line Liguo Yu and Srini Ramaswamy Evolution and maintenance of software product lines

29. PL configuration management and evolution model • Separation of responsibilities • The configuration management of software product line is divided into two domains, the production domain and the product domain. • Production domain manages the evolution of components, assets (core assets and custom assets), and core instances. • Product domain determine the evolution of custom parts of a product. Evolution and maintenance of software product lines

30. 2D Evolution of Software Product Schach and Tomer Evolution and maintenance of software product lines 30

31. 2D Evolution of Software Product • Development axis, along which versions are developed; • Maintenance axis, along which artifacts are modified • φ - the initial (empty) artifact, prior to any development action • Ri, Si, Di, and Ci - versions of requirements, specification, design and code Evolution and maintenance of software product lines

32. 3D Evolution of Software Product Evolution and maintenance of software product lines 32

33. 3D Evolution of Software Product • Reuse introduces additional dimension (axis) • How core assets, can be constructed, or acquired, independently of each other • Acquiring a core asset: core assets are transferred to specific products • Mining an existing asset: specific artifacts may become core assets. Evolution and maintenance of software product lines

34. PL Evolution Tree Evolution and maintenance of software product lines 34 Shach and Tomer

35. Risks of PL Evolution (1) • Consistency • Threat: as changes accumulate, related assets might be changed in different directions and no longer be compatible • Mitigation: planning for evolution by specifying its direction and designing defensively. An evolution plan should be then created for each related asset. If a constraint prevents a consistent change to a related asset, the process must be rolled back so that an alternative can be tried Evolution and maintenance of software product lines 35

36. Risks of PL Evolution (2) • Completeness • Threat: given changes to a large number of assets, an association could potentially be lost or rerouted during evolution, resulting in an asset being omitted from a configuration and blocked from further changes • Mitigation: periodical inspection of the output of a change process and comparison with the input. Results should be specified clearly in the evolution plan Evolution and maintenance of software product lines 36

37. Risks of PL Evolution (3) • Correctness • Threat: changing an asset might introduce a defect into it • Mitigation: specifying the direction of evolution to include a design for the change. Changes to assets should undergo the same inspection as the original asset. Evolution and maintenance of software product lines 37

38. Implementing Evolution:“Evolve Each Asset” Pattern* *Clements and Northrop Evolution and maintenance of software product lines 38

39. “Evolve Each Asset” • “Technical Planning” provides skills and techniques needed to develop a work breakdown structure to scope and estimate the work • “Data Collection, Metrics, and Tracking” provides the data, techniques, and algorithms that support the estimation and tracking of progress against the plan • Product Asset (PA)data used to evaluate the quality of evolution • Tools used to build an asset would also be used to evolve it • “Process Definition” is required if the asset’s evolution causes a change in the technology behind the asset, and a new process for the evolved asset is needed • The evolved asset is placed under configuration management, and made available Evolution and maintenance of software product lines 39

40. Evolution process (1) • Initiate Evolution • Architecture evaluation initiates the evolution of requirements, architecture, or components • System-level inspections and tests initiate the evolution of architecture or components • Unit and integration tests typically initiate evolution only in the components • User feedback initiates evolution in a product, particularly its requirements • Feedback from product builder to core asset builder can initiate the evolution of any core asset Evolution and maintenance of software product lines 40

41. Evolution process (2) • Develop an Evolution Plan • Feedback is analyzed to determine whether there should be several independent changes or just one coordinated attack. • For each change, the primary asset to be evolved is identified. • A change impact analysis is conducted to scope the evolution effort. • Maintenance metrics are used to evaluate required effort. • Plan is developed for the evolution Evolution and maintenance of software product lines 41

42. Evolution process (3) • Apply Transformations • Evolution plan identifies the transformations that will be used to modify each asset • Applying transformations to one asset might lead to the transformation of others identified during change impact analysis • Examples: • Refactoring: module structure of software assets is changed by reallocating and regrouping behaviour found in other structures • Reconfiguration: changing the objects that implement the asset • Customization: changing existing assets to satisfy new requirements that are related to existing ones • Model Transformations Evolution and maintenance of software product lines 42

43. Evolution process (4) • Accept the Evolved Assets • The evolution plan defines the testing activities that determine whether the newly modified asset is consistent with the other core assets. • The evolution plan might call for the immediate update of several existing configurations (e.g., if defect repairs are needed), or the asset might be incorporated in a new configuration (e.g., in a new version of the product or through its use by another asset) • Configuration controls is used to manage configurations Evolution and maintenance of software product lines 43

44. Change Impact Analysis • Change impact analysis provides a means of predicting which assets will be affected by a specific change before the change is made • Using that analysis, the analyst can determine whether the benefit from the change is worth the effort required to make it • Involves • conducting a traceability analysis to identify impacted places • identifying the interactions affected by the change • evaluating the effect of changes on assumptions • identifying new constraints • identifying regression tests Evolution and maintenance of software product lines 44

45. Parts of Software w.r.t. Evolution • Evolution-critical parts — parts of the design or software that need to be evolved because of existing problems • Evolution-prone parts — parts of the design or software that are likely to evolve because the corresponding requirements are likely to change • Evolution-sensitive parts — parts of the design or software that will be expensive to evolve • E.g. depth metric in OO software identifies classes that are near or at the top of inheritance hierarchies. The higher the class is, the higher the number of dependencies and the bigger the change impact will be if the class is chosen for evolution Evolution and maintenance of software product lines 45

46. PL evolution and comprehension • Successful evolution of SPLs requires comprehension of the impact change. • If a product has a (security) bug, it is necessary to identify all products (deployed and under development) that are affected. • If a feature is added or removed it is necessary to assess the impact on all products, e.g., to determine if an already deployed product can be maintained using the current product line or if an older version of the product line needs to be used. • Only, if all changes can be traced and reasoned about it is possible to determine how a changed requirement affects the products. Evolution and maintenance of software product lines

47. Contents • What is software product line (PL)? • PL development • PL evolution • Porter’sFiveForcesModel • PL maintenance • Guidelines for PL evolution and maintenance Evolution and maintenance of software product lines 47

48. Essential PL activities • Activities are all essential, inextricably linked, and highly iterative, and can occur in any order. • Strong feedback loop between the core assets and the products. • Core assets are developed or procured for later use in the production of products. • Existing products may be mined for generic assets which are then migrated into the product line's core asset base. • Product development may lead to revisions of existing core assets or new core assets • Management to control resources in the development and sustainment of the core assets. • New products must align with the existing core assets, • Core assets must be updated to reflect the new products that are being marketed. SEI, A Framework for Software Product Line Practice, Version 5.0. Evolution and maintenance of software product lines

49. External Forces for Change:Porter’s Five Forces Model Evolution and maintenance of software product lines 49

50. Porter’s forces Chastek et al. Evolution and maintenance of software product lines