1 / 25

Enhancing the scope of CSCI577ab with Software Product Line Engineering

Explore how Software Product Line Engineering (SPLE) can enhance the scope of CSCI577ab, focusing on methodologies, challenges, and solutions in developing diverse software products efficiently and effectively.

gibsonr
Download Presentation

Enhancing the scope of CSCI577ab with Software Product Line Engineering

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. Enhancing the scope of CSCI577ab with Software Product Line Engineering Kevin Ha April 27, 2011

  2. Outline • Introduction • Motivation • Software Product Line Engineering (SPLE) • Framework • Challenges • Solutions • Knowledge and Skills to adopt SPLE • Additional artifacts • Summary • References

  3. Introduction • Software Engineering in CS577ab • Provides students SE foundations • Gives students hands on experience • Materials are tailored for one of a kind system • Industry • “First to Market” mentality • Similar software for cell phone devices, software applications, automobiles, GPSs, radars, air defense systems, etc. • Favors product line approach

  4. Motivation • Bridging the gap between skills taught in 577ab and skills required in industry • Suggest Ideas to enhance scope of CS577ab to better prepare students for an immediate contribution to the SE industry.

  5. What is SPLE? • Paradigm for developing a diversity of similar software intensive systems (similar products) • At low costs (benefit from reuse) • In short time (improve time-to-market) • With high quality (benefit of reuse)

  6. Key to SPLE • Is to determine the • Commonality • Artifacts and properties shared by all products • Core assets (implement most product functionality) • Variability • Artifacts and properties that make the products different • Support the variable functionality to make the products different

  7. Framework for SPLE Process to define the commonality (core asset) and variability of the products. Process to derive applications from the domain artifacts (custom assets). • Having separate processes provide separation of concerns • robust product line platform • establish individual, customer or market specific products

  8. Modeling Variability • Two approaches • Integrate variability information into existing models • Dedicated variability model • Orthogonal Variability Model (OVM)

  9. Change Control Problems • Complicated configuration Identification • Configuration Management of single system • Collection of 1 history (version) of versioned objects • Example: WelcomFaith has 1 history of say WF and it has a collection of objects (artifacts, code files, etc.) with different version for each object.

  10. WF • WelcomeFaith = WF • Simple, not too bad to manage

  11. Complicated Configuration Identification (Cont’d) • Configuration Management in SPLE • Each core asset and custom asset combination is a different configuration • Example: Command and Control (C2) air defense system is a product line supporting two products. • Product 1 configuration combines the core asset with history of “common” and the custom asset with history of say “USA” • Product 2 configuration combines the same core asset “common” and the custom asset with history of say “Germany”

  12. Common Assets USA • US Air Defense System Product = Common (including variation Points) + USA • NATO Air Defense System Product = Common (including variation points) + Germany Core Assets (Common) GERMANY … Variation Points (Interfaces)

  13. Change Control Problems (Cont’d) • Change in variation point (core asset interface) can force changes in all products using the new version of the core assets • Different product release constraints • Schedule • Quality • Product Line Decay • New similar functionality implemented in custom assets • Erosion of SPLE benefits

  14. Root Cause • Shared core assets must satisfy the sometimes conflicting needs of different stakeholders (US and NATO)

  15. Change Control Solutions • Do not have to use latest version of Core asset • Solves change in variation point • Solves different product release constraints • Product specific branch version of core asset • Too much can void the benefit of SPLE

  16. US product is still using the latest version of Common Germ 2 Germ 1 Diagram showing specific branched version of a core asset Canadian ADS Common 6 Common 5 Common 4 Common 3 Common 2 Common 1 Artifact XYZ

  17. Solutions (Cont’d) • Core Change Control Board (CCB) • Consists of Subject Matter Experts (SME) • Negotiate with different stakeholders • Carefully review potential changes • Is it product specific changes? • Determine whether fake core changes are appropriate? • Constant work to reduce/eliminate decay • Folding back core changes

  18. Solutions (Cont’d) • Higher Quality Core Assets • High quality core assets are essential • Smaller core assets changes = smaller number of change control problems

  19. Knowledge/skills for SPLE? • What do we need to know for adopting PLSE? • Software Architecture • Need to consider commonalities and variation points of product lines • Programming Techniques • Knowing pros and cons and associated costs • Cost Estimation • Need to consider costs to maintain the core assets. • Might be expensive • Who will pay for it? • Configuration Management

  20. Additional SPLE Artifacts • Domain artifacts • Application (product) artifacts • Variation points artifact • Whether integrated or dedicated (OVM) • Product history (branch) artifact • Artifact capturing all decisions made by the CCB

  21. If OVM is Selected • OVM artifacts should cover • Variation points (what vary?) • Variant (How do they vary?) • Variability constraints • Visibility of variability (who is it documented for? Internal or external variability?)

  22. Summary • Introduced SPLE • Framework • SPLE challenges and solutions • Knowledge and skills needed to adopt SPLE • Additional SPLE artifacts • SPLE lectures coming to future CS577ab??

  23. References [1] K. Kim, H. Kim, and W. Kim, “Building Software Product Line from the Legacy Systems “Experience in the Digital Audio & Video Domain” 11th International Software Product Line Conference, pp.171-180, 2007. [2] R. Capilla and J. Duenas, “Light-weight product-lines for evolution and maintenance of Web sites” 7th European conference on Software Maintenance and Reengineering, pp. 53-62, IEEEXplorer, 2003. [3] J. Bayer, O. Flege, P. Knauber, R. Laqua, D. Muthig, K. Schmidt, T. Widen and J. M. DeBaud, “PuLSE: A Methodology to develop Software Product Lines” 5thSymposium on Software Reusability, pp.122-131, ACM Press, Los Angeles, USA, 1999. [4] J. Bergey, L. O’Brien and D. Smith. “Mining Existing Assets for Software Product Lines”, CMU/SEI-2000-TN-008, Technical Report, Software Engineering Institute, Carnegie Mellon University, Pittsburg, PA (USA), 2000. [5] J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, H. Obbink and K. Pohl, “Variability Issues in Software Product Lines”, Software Product-Family Engineering, LNCS vol 2290, Springer-Verlag, pp. 13-21, 2002. [6] P. Clements, “Successful Product Line Engineering Requires More Than Reuse” 8th Workshop onInstitutionalizing Software Reuse, pp. 63-68, Ohio (USA), 1997. [7] P. Clements, “On the Importance of Product Line Scope”, Software Product-Family Engineering, LNCS vol 2290, Springer-Verlag, pp. 70-78, 2002.  [8] J. M. DeBaud and P. Knauber, “Applying PuLSE for Software Product Line Development” 2nd European Reuse Workshop, pp. 73-94, Madrid, Spain, 1998. [9] F. Loesch, R. Bosch, and E. Ploedereder, “Optimization of Variability in Software Product Lines” 11th International Software Product Line Conference, pp. 151-162, 2007. [10] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley, 2001. [11] S. Deelstra, M. Sinnema, J. Nijhuis, and J. Bosch. COSVAM: A technique for assessing software variability in software product families. In Proceedings of the 20th IEEE International Conference on Software Maintenance (ICSM’04), pages 458–462, September 2004.

  24. References (Cont’d) [12] D. L. Parnas. “Software aging”. In Proceedings of the 16th International Conference on Software Engineering (ICSE’94), Sorento, Italy, 1994. IEEE Computer Society Press. [13] A. Metzger, and K. Pohl, “Variability Management in Software Product Line Engineering” 29th International Software Engineering Conference, pp.186-187, 2007. [14] O. Kobayashi, “What Should Software Practitioners Know for Adopting Product Line Software Engineering?”, 11th Asia-Pacific Software Engineering Conference, pp. 565-566, 2004. [15] M. Jiang, J. Zhang, H. Zhao, and Y. Zhou, “Maintaining Software Product Lines – an Industrial Practice”, IEEE International Conference on Software Maintenance, pp. 444-447, 2008. [16] M. Staples, “Change Control for Product Line Software Engineering”, 11th Asia-Pacific Software Engineering Conference, pp. 572-573, 2004. [17] C. Krueger, “Software Product Line Reuse in Practice”, 3rd IEEE symposium on Application-Specific Systems and Software Engineering Technology, pp. 117-118, 2000. [18] A. Fuggetta and E. Nitto, “Product lines: what are the issues?”, 10th International Software Process Workshop, pp. 51-53, 1996.

  25. Thank You!

More Related