1 / 11

Maximizing Efficiency of Product Derivation

page 2. February 12, 2012. . Agenda. page 3. February 12, 2012. . Participants. page 4. February 12, 2012. . Problems. that cause inefficiencies in product derivation. page 5. February 12, 2012. . Domain Engineering. How to predict future products/market?How far can you predict the market?When is the domain engineered sufficiently?Solid architecture? How well to define the architecture?What is the expected lifetime?What is the reasonable size?When to develop and pr30395

jase
Télécharger la présentation

Maximizing Efficiency of Product Derivation

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. Maximizing Efficiency of Product Derivation 2nd Groningen Workshop on Software Variability Management

    2. page 2 February 13, 2012 Agenda

    3. page 3 February 13, 2012 Participants

    4. page 4 February 13, 2012 Problems that cause inefficiencies in product derivation

    5. page 5 February 13, 2012 Domain Engineering How to predict future products/market? How far can you predict the market? When is the domain engineered sufficiently? Solid architecture? How well to define the architecture? What is the expected lifetime? What is the reasonable size? When to develop and provide what? How generic should the components be?

    6. page 6 February 13, 2012 Application Engineering How to handle the Not-Invented-Here syndrome? How to make a component potentially reusable? How to map your requirements to existing solutions (configuration)?

    7. page 7 February 13, 2012 General How to distinct between AE and DE? Sometimes the limit is blurred? What kind of knowledge has to be provided to make a component reusable? Incentives to make the knowledge of domain experts explicit? When and how to capture it? How to increase the efficiency of testing? When to test what? What scientific solutions are applicable in certain contexts?

    8. page 8 February 13, 2012 Case Study: HP Consumer Products Software Team Inkjet printers, scanners, cameras, PDAs, home PCs Every year: > 200 products, up to 6 software variants/product Slowly evolved towards a Software Product Line Opportunistic re-use: Hey, thats cool! Can I use it, too? Planned re-use: Ill re-use it unless its not perfect for me. Managed re-use: Ill reuse it but they dont listen to me. Software platform: Well negotiate what it needs to do. Software Product Line Formally admitted they were a Software Product Line in May of this year.

    9. page 9 February 13, 2012 Team Evolution

    10. page 10 February 13, 2012 Situation Teams still coming to terms with Software Product Line approach Some basics arent yet in place Early efforts focused on clear charters, strategy, scope and requirements architecture, tools & process work has lagged Key Challenges: Minimize resources and time required for product-specific software releases Minimize time to market for new features Question: How do we maximize the efficiency and effectiveness of our product derivation?

    11. page 11 February 13, 2012 Discussed solutions Appropriate technology for the scale of the product lines AOP vs. components vs. .... Binding times Appropriate level of architecture Define a product derivation strategy Testing: what and when Roles and responsibilities (DE, AE, Mktg) Process (SW, FW, HW) Integrated development planning for smooth release of new functions

    12. page 12 February 13, 2012 Discussed solutions (cont.) Make the expert knowledge explicit Configuration options Dependencies Variability mechanisms Automate the knowledge in a configuration tool Use an integrated tool set (as integrated as feasible) Define variation point mechanisms Guidelines on when to use which mechanism Define quality standards for components

More Related