NEWS AT SEI
This library item is related to the following area(s) of work:Software Architecture
This article was originally published in News at SEI on: March 1, 2005
In a previous column ("Rethinking the Software Life Cycle"), we looked at the traditional software-development life cycle in the context of the architecture-centric methods that we have developed at the Carnegie Mellon Software Engineering Institute (SEI) over the past 10 years. These methods include the SEI Architecture Tradeoff Analysis Method (ATAM) [Clements 02], the SEI Quality Attribute Workshop (QAW) [Barbacci 03], the SEI Attribute-Driven Design (ADD) Method [Bass 03], the SEI Cost Benefit Analysis Method (CBAM) [Bass 03], and SEI Active Reviews for Intermediate Design (ARID) [Clements 02].
This column concentrates on the QAW and the ADD methods to show how they can be enhanced and integrated with a software-development life-cycle process to help organizations methodically design complex software-intensive systems. The QAW provides a way to elicit and articulate detailed quality-attribute requirements for a system, which the architecture must support. ADD is an architectural design method that starts with statements of quality-attribute requirements and guides the architect through a series of design decisions that help to meet those requirements. As such, these two methods can be integrated.
There are three ways that the QAW and the ADD method can be made to work together:
Knowing that ADD is to follow, we can tailor the QAW in the following ways:
Knowing that a QAW has already been conducted, we can tailor the ADD method in the following ways:
Additional activities to bridge the methods would follow the QAW in preparation for applying the ADD method:
The results should be analyzed immediately after the QAW, and the post-QAW planning workshop should follow the analysis. The transformation of the scenarios could occur during the action-planning workshop. Other requirements analysis would occur in parallel with the QAW, for example, refinement of the functional requirements into the form of use cases. Scenarios generated during the QAW could lead to multiple use cases.
At the completion of the QAW, information associated with the quality attributes will have been generated and prioritized, but this information will not have been put into context. The first step toward providing this context would be to analyze the QAW results. The suggested steps for this analysis are described below:
After the QAW results have been analyzed, a post-QAW planning workshop can be held to review concerns expressed in the results analysis and determine what further actions can be taken to aid the ADD approach. Suggested activities for such a workshop are listed below:
Some scenarios from QAW may be useful directly in ADD. Other scenarios may need to be refined and allocated to hardware, software, people, or data in the system architecture. The ADD method can be used on the software-architecture portion of the system architecture.
The QAW stakeholders often express high-level scenarios of the following types:
A QAW scenario may not distinguish between what is done by operators and what is done by the automation, especially where multiple operators are involved in the scenario. In this case, the architect will have to review the existing documentation (such as those documents listed above) and transform the original scenario into a group of overlapping scenarios, which combine to provide the original scenario. Some examples of such transformations are as follows:
The ADD method has an activity for refining use cases, constraints, and scenarios that could be applicable here. Requirements and constraints flow from the module chosen to decompose to its child modules. Quality scenarios also have to be refined and assigned to the child modules. This is done in one of the following ways:
More details of this approach can be found in Integrating the Quality Attribute Workshop (QAW) and the Attribute-Driven Design (ADD) Method (CMU/SEI-2004-TN-017) by Nord et al. [Nord 04].
The benefits of such an integrated method would be the combination of otherwise duplicative steps, more productive use of stakeholders’ scarce time, more timely collection of necessary information, and more effective use of that information to achieve the desired architectural outcomes. Some work has already been done to demonstrate the benefits of such an approach. General scenarios are routinely used to help guide the refinement of scenarios during the QAW. A utility tree is constructed after the QAW if requested by the sponsor or if a follow-on ATAM is contemplated. The integrated approach has been applied to the design of patient-monitor management software [Lounento 05]. Further work remains to be done to verify the benefits of our proposed integration approach through pilot projects with customers. The goal of such projects is to provide tailored architecture methods to help customers add architecture-based and quality-attribute-based thinking to their planning and development efforts.
Barbacci, M. R.; Ellison, R.; Lattanze, A. J.; Stafford, J. A.; Weinstock, C. B.; & Wood, W. G. Quality Attribute Workshops (QAWs), Third Edition (CMU/SEI-2003-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2003.
Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd edition. Boston, MA: Addison-Wesley, 2003.
Clements, P.; Kazman, R.; & Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA: Addison-Wesley, 2002.
Lounento, H. Quality Attribute Based Architecture Design of Patient Monitor Management Software (Master’s Thesis). Helsinki, Finland: Laboratory of Software Business and Engineering, Department of Computer Science and Engineering, Helsinki University of Technology, 2005.
Nord, R. L.; Wood, W. G.; & Clements, P. C. Integrating the Quality Attribute Workshop (QAW) and the Attribute-Driven Design (ADD) Method (CMU/SEI-2004-TN-017). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2004.
Robert Nord is a senior member of the technical staff in the Product Line Systems Program at the SEI where he works to develop and communicate effective methods and practices for software architecture. Prior to joining the SEI, he was a member of the software architecture program at Siemens, where he balanced research in software architecture with work in designing and evaluating large-scale systems. He earned a PhD in computer science from Carnegie Mellon University. Nord lectures on architecture-centric approaches. He is co-author of Applied Software Architecture (1999) and Documenting Software Architectures: Views and Beyond (2002).
William Wood has been a member of technical staff at the SEI for 18 years. During this time he has managed a technical program and technical projects and provided technical support to the program development organization. He is currently working in software architecture with a number of clients. Previously Wood worked in process control automation for Westinghouse Electric Corp. for 20 years. He has an MSEE degree from Carnegie Mellon University, and a BSc in physics from Glasgow University, Scotland.
Paul Clements is a senior member of the technical staff at the SEI, where he has worked for 10 years leading or co-leading projects in software product line engineering and software architecture design, documentation, and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998; second edition, 2003), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also written dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a BS in mathematical sciences in 1977 and an MS in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a PhD in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.