1. Questions and support on assignment -------------------------------------- What are your current problems? 2. SPLC 2008 ------------ Check program linked from home page! Papers of note: Providing Feedback from Application to Family Engineering - The Product Line Planning Game at the Testo AG Carbon, Knodel, Muthig, Meier Abstract: Product line organizations need to continuously invest into their product line infrastructure to minimize its degeneration and thus maximize its viability. Besides feedback on a strategic level to monitor changing customer requirements, technical feedback with respect to reusing product line components needs to be provided from application to family engineering. After successfully installing a product line at Testo, such a feedback loop on the technical level was established. Our strategy in this relatively small development organization was to adapt the agile practice "planning game" to their product line context. The results of three runs conducted so far show that the product line planning game is an efficient means to establish a feedback loop from application to family engineering. Testo will continue using the product line planning game in the future. * Adapt Planning Game to PL to gather feedback from application to domain/family eng: * Mapping PL roles to planning game roles - app engs are customers to family engs * Reuse stories - user stories of appl eng focusing on tech aspects of reuse * feedback of app engs when reusing a certain spl component * reuse improvement suggestions - solutions on tech implementation level * Adapting decision making process (Choose scope) in commitment phase * evolution of components must be taken into account - fam engs must take that decision * Tested in 3 runs * 20-26 stories in 1 hour * Evaluating Flexibility in Embedded Automotive Product Lines Using Real Options Gustavsson, H. Axelsson, J. Abstract: Embedded automotive architectures and software need to support a large number of vehicle product lines over many years of production. This leads to a complexity and many uncertain factors when developing such systems and a need for support in the design process. An evaluation method using real options provides the opportunity to analyze the cost of designing for flexibility to cope with a future growth of a product line, based on the estimated value of the future functionality. In this paper real options is applied on a case within the automotive industry. To improve the usability an evaluation process is defined to aid engineers. This process provides a way of valuing system designs and enables the engineer to think about the future in a systematic manor. The value of a flexible design can thereby be quantified and the proposed process shows how it can be accepted by practitioners. HomeAway's Transition to Software Product Line Practice: Engineering and Business Results in 60 Days Krueger, C.W. Churchett, D. Buhrdorf, R. Abstract: The genesis of HomeAway, Inc. was startup by accretion - eight companies in the web-based vacation home rental market were acquired and merged. The technical solution during the merger and acquisition phase was to assimilate the software functionality of each of the eight companies into a one-size-fits-all application that could be configured with runtime settings to support the look-and-feel of the original eight. When rapid growth and an aggressive business plan pushed the one-size-fits-all approach beyond its limits, HomeAway decisively applied the 3-tiered software product line (SPL) methodology and the gears unified SPL Framework to transition to a software product line practice. This case study explores how HomeAway leveraged the 3-tiered methodology and gears to make their transition, accelerate software development, reduce defect density, lower development overhead, and extend the scalability of its portfolio to better achieve its aggressive business goals - all within 60 days. * 3-tiered SPL Methodology - 3 tiers of capabilities and benefits in a gradual shift from single-system dev to SPLE * Base tier: Variation Management and Automated Production (tactical set of dev capAndBen) * Middle tier: Core Asset Focused Dev (eng management capAndBen) * Top tier: Feature Based Portfolio Evolution (strategic capAndBen for business operation) * October 2006: Merge 8 different sites backend but keep the front end differences * One-size-fits-all executable with runtime selection mechanisms for variation * Didn't scale, 29 different variation solutions in the source code * Built the case for SPLE: Eng case + Business case * One hour presentation 3. Feedback on designs ---------------------- Group 1: * Clear language. Correct format. Easy to understand, good flow of the text. * Some citations are strange with both number and name and year. Standardize! * PLPA and BAPO described at too high level. Detail somewhat! * Not clear how the PLPA cycle is realized in your design. Iteration is unclear. * Actual questions have not been detailed; based on some formalism or created by researchers? Group 6: * A bit too direct in intro. Elaborate more on what SPLE is and why it is interesting. * Details on how you are going to do the study is missing. Which roles will you interview etc? * Not clear where the examples of questions comes from. Based on PLPA or BAPO etc? Group 9: * Format is not correct. Ensure you use the correct IEEE formatting files. There can also be problems when converting to PDF. Ensure fonts are included and you only use the standard ones (but the formatting files should disallow anything else). * Language is sometimes unclear. You must work on improving it before submitting your final report. Example: "...but not well profound" ?? * Way too little information on how the study will be carried out. You need to get/decide the details asap! Group 7: * Format is not correct. Ensure you use the correct IEEE formatting files. There can also be problems when converting to PDF. Ensure fonts are included and you only use the standard ones (but the formatting files should disallow anything else). * Intro should introduce not only the company but SPLE, that this is a case study within a course etc. * "...deterministic questions" unclear * Good with questions in different areas. Not clear how you derived them though; describe how in methodology section! Marculescu et al: * Fairly well developed and detailed design. * When you include a figure wyou have not done yourself you must refer to the paper/book it is taken from in the figure caption! * Instead of listing examples in a parentheses you should add a comma and "e.g." then list the examples. * You sometimes lack articles like "a", "an" and "the". Example: "Within the framework of THE SPLE course" * *