1. Practice
1.1. Change propagation between core-assets and products
1.1.1. Supporting Evidences?
1.1.1.1. "Updates to products may be required whenever a new version of an asset is created. For every product produced from the original asset, an update operation is required. If the software assets are mutable during production then the update operation may require a manual merge for each product."
1.1.1.2. "In practice the upgrade delay differs significantly for the different projects: some tend to upgrade rather quickly, some do not upgrade for a long time, even when not close to a release. However, access to new features and bug fixes is only available by upgrading"
1.1.1.3. "Product-to-asset feedback (see Feedback, arrows in Figure 6). If asset inputs are mutable during production, then evolutionary changes to a product may need to be fed back to t__originating assets. Resultinğ chanğes to ašset inputs may require that updates be recursively applied to all other products created from the asset, as described in the previous section."
1.1.1.4. Some of them [product engineers] develop some or all of their new features together in a single branch which is altogether delivered to the ESP team.
1.1.1.5. The ESP team then in cooperation with the projects ensures that [feedbacked] individual non-mandatory features can be separately used in the platform.
1.1.1.6. "The potential loss of essential changes performed on AE level (visualized by scissors in the Figure 1) is a major concern for real-world SPLs due to the resulting increased cost of recreating the changes and the possibly reduced quality of the solution."
1.1.1.6.1. Why?
1.1.1.7. "In a software product line organization many products may be under development at the same time. Each product will need some product unique artifacts but some of these will be promoted to core assets eventually. The CM process can interact with the promotion process to ensure that the artifact that becomes a product line-wide asset still supports the original use that brought it into existence. One product line evolution guideline is that promoted assets should remain backward compatible with their previous use."
2. Set Problem Statement
2.1. Both feedback propagation and update propagation are time-consuming and error-prone
3. Assess Problem as Difficulties
3.1. Ascertain Consequences
3.1.1. productivity drop & lower time-to market
3.1.1.1. Supporting Evidences?
3.1.1.1.1. Releases of the core assets that are not synchronized with product releases are another source of disruption to the overall product development schedule.
3.1.2. Reuse decay
3.1.2.1. Supporting Evidences?
3.1.2.1.1. "If integration in the platform is too restrictive or too experimental then projects will start clone-and-own outside the platform and in the second case do not upgrade."
3.1.2.2. What follows from ...?
3.2. Ascertain Causes
3.2.1. VCSs not tuned for SPL specifics
3.2.1.1. Supporting Evidences?
3.2.1.1.1. "most of them [Configuration Management tools] do not directly support the functionality required for the CM to be useful in a product line context. Many of them can be "convinced" to provide the necessary functionality, but this convincing is a time-consuming task requiring specialized knowledge. If the organization fails to assign someone to customize the CM system for the product line, the CM tool support is likely to be ineffectual. Such a person needs to have both a good understanding of the product line processes and a solid grounding in CM."
3.2.1.1.2. However, product derivation tools and SCM tools have very different approaches and data models and they are not well integrated with each other. While product derivation and product evolution must be supported in SPL, no existing SPL or SCM tool can fully support their needs.
3.2.1.1.3. The process of product derivation (i.e. exploiting the provided variabil- ity in the software product family to create product variants) is only partially supported by tools. Product derivation is about more than this. It includes: – Selecting components. Reusing components provided by the software prod- uct family. – Overriding components. Replacing provided components with alternative implementations (provided by the software product family or product specific). – Modifying provided components. Sometimes product requirements conflict with product family requirements. Adapting such code in the derived product is a solution that despite its disadvantages is preferred in many companies. – Providing new variants for existing variation points (e.g. implementing component interfaces) – Adding product specific components and architecture. – Configuring reused, modified and product specific components. We observe that none of the variability management tools fully supports all of these activities. Secondly, we observe that the product derivation process, like the rest of the development process, is iterative. In other words, it is not a one time activity but a recurring activity during the evolution of a product.
3.2.1.1.4. " For every product produced from the original asset, an update operation is required. If the software assets are mutable during production then the update operation may require a manual merge for each product."
3.2.1.1.5. Another issue was that some tools were simply not capable of supporting efficient product line development because they do not allow for creation of product-specific artefacts from a shared artefact in the required way.
3.2.2. Lack of guidelines for branching and merging
3.2.2.1. Supporting Evidences?
3.2.2.1.1. " .. a proliferation of isolated modifications to product line software that are not adequately merged back to the common software baseline. "
3.2.2.1.2. "The branch and merge process in multiple model developments in parallel were not established (R3.3 and R3.4). These are clearly deficiencies in the implementation of the management process, prevented from merging the software parts that were developed, and caused a disorderly derivation of software branches."
3.2.2.1.3. "A problem arises if a derived variant requires further functionality or bug- xes from the SPL (DE). In this case, the aforementioned derivation process is performed again at tl (step ), which leads to the generation of a new working copy for the variant. All changes performed for the variant (AE) on artifacts stemming from the SPL, independent of the kind of change, are overwritten by the artifact versions of DE level."
3.2.3. Large number of products and core-assets
3.2.3.1. Supporting Evidences?
3.2.3.1.1. "Also the integration work and effort for porting features developed with code belonging partially to the platform and partially to the product specific code - such as feature and Y in Figure 2 - to other products became a major part in the ESP teams work load, reducing the time to work on improvements."
3.2.4. Conflicting changes between AE and DE
3.2.4.1. Supporting Evidences?
3.2.4.1.1. "artifacts may evolve separately, leading to conflicts when attempting to regenerate the corresponding variant from domain artifacts. Current methods for evolving SPLs do not tackle these conflicts."
3.2.4.1.2. "It not only leads to major reintegration efforts (mapping to big jumps in the economic curve), but it also usually entails significant synchronization efforts and quality problems."
3.2.4.1.3. "the freedom for projects to decide on the platform upgrade (building the product on a newer platform release). There is a trade-off between isolation from outside changes (calling for infrequent updates) and the need for access to some bug fixes and new features in later releases. The platform is designed to be used as a coherent piece. Picking individual items for integration into older releases of the ESP is not supported, since this would require a back-port of the change (done by the project). It also becomes very hard to integrate new features if they come from projects using much older releases."