1 / 14

Relating Product Line Adoption Mode and Transition Process

This workshop overview discusses various strategies and patterns for adopting product lines, including economic considerations and planning techniques. It explores different adoption situations, such as entering new markets and incremental versus big bang development approaches. The workshop emphasizes the importance of architectural decisions on product line characteristics and variability management. Additionally, it provides insights into efficient portfolio planning, reuse infrastructure, and the impact of variability on costs and effort required. The event aims to equip participants with a comprehensive understanding of effective product line adoption strategies.

heinz
Télécharger la présentation

Relating Product Line Adoption Mode and Transition Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Relating Product Line Adoption Mode and Transition Process PLEES Workshop 23. September, 2003 Klaus Schmid schmid@iese.fhg.de

  2. Overview • Product Line Adoption Situations • Adoption Strategies • Adoption Patterns • Resulting Economic Patterns • Product Line Planning Techniques • PL Planning and its Relation to Adoption and Evolution • An Economic Model to Optimize Product Line Adoption • Summary

  3. Market 1 Market 2 Product Line Adoption Situations • Independent • No previous systems • Entering a new market / domain / sub-domain • Willingness to develop systems from scratch • Project-Integrating • Systems exist • System-Development needs to continue • Reengineering-Driven • Systems exist - but no basis for PL • Knowledge is insufficient / other means are too costly • Leveraged — characteristics of previous ones • Product Line in Place • Entering a new market / domain / sub-domain How to introduceproduct lines?

  4. Incremental Product Line development Product Line Development Effort Investment Number of Products Product Line Adoption Patterns • Incremental • You build it on your way • Dimensions of Incrementality: • products • functional areas (sub-domains) • Big Bang • You plan it — You do it.

  5. Product Line Adoption Economics • Big Bang  Incremental • Jumps in incremental • correspond to investments in migrating to product line assets • total sum higher than in big bang • Lines • correspond to products built with partial infrastructure Optimal Curves Effort Number of Products • Angle • reduced in each investment • final angle still steeper • go for best ROI first (if risk controllable) — best reduction of angle • Endpoint • higher for incremental • Why to go for incremental anyway? • Risk control!!

  6. How Do I Plan For Product Line Adoption?

  7. Product Line Planning Techniques • Product Portfolio Planning • Define what the products are • Interface with product management / Market concerns • Typically workshops • Domain Potential Analysis • Identify benefits and risksrelated them to functional sub-domains • Assessment Approaches (e.g., PuLSE-B&R) • Reuse Infrastructure Scoping • Identify parts that should be packaged as reusable assets( architecture impact) • Rather fine-grained analysis • Closest to implementation

  8. PL Planning and Its Relation to Adoption

  9. Value-Based Adoption and the Architecture Impact of product characteristics on the architecture: • How often will we need a certain variation? • How certain is it, we will need it? • What are the costs of variation mechanisms? Assumptions: • Adding variabilities costs effort(variability mechanism + effort capability) • More generic code is more complex, thus more costly to maintain • Late implementation is more costly than if it was planned right away • The less „places“ a change impacts, the less costly • Architecting for a functionality reduces the number of impacted positions • Discounted Cash-Flow Analysis

  10. Value-Based Adoption and the Architecture Example • Some functionality (in our case distribution support) can be required: • We are not sure • The support is costly to build • It can not always be present • What to do? • The numbers are taken from the example, but the basic characteristics of the functions relate only to their structure

  11. Value-Based Adoption and the Architecture • Is up-front introduction of variability better? • The number of impacted positions (i.e., the architecture) is key to answer this question! There is a gap between up-front and later introduction VIP = variability impact point

  12. Value-Based Adoption and the Architecture • The effect of probability • Only for very low probabilities the total costs are reduced

  13. Architectureadvantage Value-Based Adoption and the Architecture • Changing the architecture changes the approach • Up-front architecting might be appropriate even if up-front implementation is not!!

  14. Conclusion and Further Work • Conclusions • Categorizations of product line adoption situations were given and different approaches for dealing with them were discussed • Detailed recommendations for product line planning were given • Planning Look-Ahead • Relative Importance of Scoping Techniques • A quantitative model was proposed that allows to derive more detailed guidelines • Amount of effort required for variability • Probability that it is needed • Characteristics of underlying development process(e.g., change effort)

More Related