NEWS AT SEI

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:

1. tailor QAW knowing that it will be followed by the ADD method
2. tailor ADD making use of the knowledge gained by conducting a QAW
3. add activities to bridge the QAW and the ADD methods

Knowing that ADD is to follow, we can tailor the QAW in the following ways:

• The information needed by the ADD method could constrain the QAW in terms of the types of scenarios generated, the stakeholders invited, the questions or issues recorded in the refinement template, and so forth.
• The notion of general scenarios was originally developed in the context of ADD. Incorporating them into the QAW would help guide scenario refinement into six parts.
• The last step of the ADD method refines the quality-attribute scenarios in preparation for the next iteration of the method on the modules of the decomposed system. Such activities might be applied to refine the system scenarios that flow from the QAW to the ADD method.

Knowing that a QAW has already been conducted, we can tailor the ADD method in the following ways:

• An enhanced QAW could help guide or take the place of the ADD step in which the architectural drivers are chosen. Mapping quality attributes to business goals is necessary to support the construction of a utility tree before applying the ADD method.
• High-priority scenarios from the QAW could inform the types of views that are selected, which would encourage designers to look at the difficult design problems first.
• In addition to quality requirements, the ADD method also takes constraints and functional requirements as inputs. QAW scenarios could help identify use cases, which are input into ADD as functional requirements. Issues and questions in refined scenarios that are further refined into themes and suggestions could provide input into ADD as constraints.

Additional activities to bridge the methods would follow the QAW in preparation for applying the ADD method:

• Analyze the QAW results.
• Hold a post-QAW planning workshop.
• Transform the elicited scenarios to be useful for ADD.

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:

1. Build an initial utility tree showing how the scenarios are organized according to the quality attributes. The scenarios of the utility tree contain an implicit measure of “business importance” from the stakeholder voting. This needs to be cross checked with the business manager. Note that the “architectural difficulty” of the scenarios would be assigned by the architects at a later time (e.g., during the post-QAW planning workshop or during the application of the ADD method).
2. Build a table showing how the scenarios map to the business goals, and identify any missing business goals that are obvious from the QAW results.
3. Build a table showing how the scenarios map to the architectural drivers, and identify any missing architectural drivers.
4. Build a table showing the architectural life-cycle processes being used and how they relate to the scenarios. Identify any missing processes implied by a scenario.
5. Develop a list of concerns resulting from the missing business goals, architectural drivers, and architectural life-cycle processes. Note concerns resulting from the lack of scenario coverage in any of the business goals, architectural drivers, and processes identified earlier.
6. Identify potential studies required and prototype development necessary to mitigate the risks and concerns that have been identified.

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:

1. Review the concerns and classify them in some manner: for example, those that can be dealt with in a cursory manner (e.g., by adding a new business goal), those that require some further exploration (e.g., by writing appropriate white papers or doing feasibility studies), and those that require extensive integration with outside agencies.
2. Determine if any of the lower priority scenarios should be refined, and refine the appropriate scenarios.
3. Have the architects add a difficulty ranking to the scenarios in the utility tree.
4. Perform flow downs of the scenarios.

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:

• operational scenarios. These scenarios describe, for example, how a system of systems responds to a stimulus while under a heavy workload.
• life-cycle process scenarios. These scenarios are largely concerned with the life-cycle processes involved with the system of systems.

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:

• A system-specific quality scenario describes the operation between a sensor detecting an event of interest and an actuator responding to the event, including a time deadline for the response; however, it ignores the manual operations involved. The architect reviews the other documentation and discovers that the scenario involves a number of operators at a number of locations using different systems. The architect must then re-express this scenario as a number of scenarios that can be used for the development of the software architecture for the interoperation between the systems, allocating timing budgets to each scenario to satisfy the original timing deadline.
• A system-specific quality scenario describes an activity involving many (hundreds of) nodes connected by a low-bandwidth communication system. The software architect knows enough from the scenario to separate the software architectural decisions from the system decisions and to build a software-architectural fragment to satisfy the scenario. However, the architect cannot verify that the scenario will be satisfied until a simulation study is executed for the environmental workload included in the scenario. In this case, he or she will probably have to work cooperatively with the system engineers.
• A 30-day quick-update requirement is levied on the system to correct some inadvertent behavior. The software architect must then describe how this requirement affects the architecture, development, integration, test, and field-deployment organizations.

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:

• A quality scenario may be completely satisfied by the decomposition without any additional impact. It can then be marked as satisfied.
• A quality scenario may be satisfied by the current decomposition with constraints on child modules.
• The decomposition may be neutral with respect to a quality scenario. This scenario should be assigned to one of the child modules.
• A quality scenario may not be satisfied with the current decomposition. If the scenario is important, the decomposition should be reconsidered. Otherwise, the rationale for the fact that the decomposition does not support this scenario must be recorded. This occurrence is usually the result of a tradeoff with other, perhaps higher priority, scenarios.

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.

References

[Barbacci 03]
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 03]
Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice, 2nd edition. Boston, MA: Addison-Wesley, 2003.

[Clements 02]
Clements, P.; Kazman, R.; & Klein, M. Evaluating Software Architectures: Methods and Case Studies. Boston, MA: Addison-Wesley, 2002.

[Lounento 05]
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 04]
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.

About the Authors

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.