Methods and Models for Evaluating Software Product Line Architecture

1. Methods and Models for Evaluating Software Product Line Architecture Software Architecture and Design Dr. Lawrence Chung Hyotaeg Jung Computer Science Department Univ. of Texas at Dallas

2. What is SPL and SPLA? • Software Product Line (SPL) • SPL is a set of products sharing a common, managed set of features which satisfy the specific needs pertaining to a selected market segment or mission or application domain, a common architecture whose services are based on the components. (by Bosch) • Software Product Line Architecture (SPLA) • SPLA defines a number of architectural components with their associated requirements and zero, one or more component implementations.

3. Evaluation Method for Single Software Product Architecture • SAAM (Software Architecture Analysis Method) • Scenario-based method • Requires system’s stakeholders to enumerate a set of scenarios • Scenarios are scrutinized, prioritized and mapped onto a representation of the architecture. • ATAM (Architecture Tradeoff Analysis Method) • Scenario-based method • Draws inspiration and techniques from the notion of architectural style, the quality attribute analysis communities, and SAAM • ARID (Active Reviewers for Intermediate Designs) • stakeholder-centric scenario-based method • Technical review approach (a niche in the spectrum of design review technique)

4. Evaluation Method Steps (1) • SAAM • Develop scenarios • Describe the architecture • Classify and prioritize the scenarios • Individually evaluate indirect scenarios • Access scenario interactions • Create the overall evaluation

5. Evaluation Method Steps (2) • ATAM • Present the ATAM • Present the business driver • Present the architecture • Identify the architectural approaches • Generate the quality attribute utility tree • Analyze the architectural approaches • Brainstorm and prioritize scenarios • Analyze the architectural approaches • Present the results

6. Evaluation Method Steps (3) • ARID • Identify the reviewers • Prepare the design briefing • Prepare the seed scenarios • Prepare the materials • Present the ARID • Present the design • Brainstorm and prioritize scenarios • Apply the scenarios • Summarize

7. Evaluation Method for Software Product Line Architecture • FAAM (Family Architecture Assessment Method) • Focusing on interoperability and extensibility • Involves the product family stakeholders in the product creation process • Emphasizes the practical know-how mechanisms and techniques • FAE (Family Architecture Evaluation) • Developed for companies and product family architects who wish to benchmark their product family engineering • Based on BAPO (Business, Architecture, Process, Organization) Model • FEF (Family Evaluation Framework) • Based on BAPO Model • Based on CMMI (Capability Maturity Model Integration) Model

8. Evaluation Method Steps • FAAM • Define the assessment goal • Prepare system quality requirements • Prepare the architecture • Review and refine artifacts • Assess architecture conformance • Report results and proposal • FAE • Evaluate framework via interviews • Review and inspect architectural artifacts • Analyze the results • Archive the evaluation framework for benchmarking

9. Our Model for Evaluating Software Architecture

10. Our Evaluation Method Steps • Present the objective • Present the business drivers • Present the software product line architecture • Present architectures of single products • Brainstorm and prioritize the quality attributes for SPLA • Brainstorm and refine evaluation items for SPLA • Brainstorm and prioritize the quality attributes for architectures of single products • Brainstorm and refine evaluation items for architectures of single products • Present the results

11. References • P. Clements, R. Kazman, and M. Klein, “Evaluating Software Architectures – Methods and Case Studies,”Addison-Wesley, 2002. • R. Kazman, L. Bass, G. Abowd, and M. Webb, “SAAM: A Method for Analyzing the Properties of Software Architectures,” in Proceedings of 16th International Conference on Software Engineering, pp. 81-90,May 1994. • M. Barbacci, P. Clements, A. Lattanze, L. Northrop, and W. Wood, “Using the Architecture Tradeoff Analysis Methods (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study,” Technical Note, CMU/SEI-2003-TN-012, July 2003. • J. K. Bergey, M. J. Fisher, and L. G. Jones, “Use of the Architecture Tradeoff Analysis Method (ATAM) in Source Selection of Software-Intensive Systems,” Technical Note, CMU/SEI-2001-TN-010, June 2002. • P. C. Clements, “Active Reviews for Intermediate Designs,” Technical Note, CMU/SEI-2000-TN-009, August 2000. • T. J. Dolan, “Architecture Assessment of Information-System Families,” Ph.D. Thesis, Department of Technology Management, Eindhoven University of Technology, February 2002. • F. Linden, J. Bosch, E. Kamsties, K. Kansala, and H. Obbink, “Software Product Family Evaluation,” in Proceedings of the 3rd International Conference on Software Product Lines, pp. 110-129, Boston, September 2004. • R. Kauppinen, “FEF – A Product Family Evaluation Framework,” Seminar on Quality Models for Software Engineering in University of Helsinki, Helsinki, September 2004. • F. Linden, J. Bosch, E. Kamsties, K. Kansala, and H. Obbink, “Software Product Family Evaluation,” in Proceedings of the 3rd International Conference on Software Product Lines, pp. 110-129, Boston, September 2004.