B. Tactics-Based Questionnaires
This appendix provides a set of tactics-based questionnaires for the seven most important quality attributes: availability, interoperability, modifiability, performance, security, testability, and usability. How do we know that these are the seven most important ones? This decision was based on an analysis of the quality attributes that were elicited from stakeholders in more than 15 years of SEI ATAM data.
In addition to these “top seven”, we include a tactics-based questionnaire for DevOps, which is a combination of tactics from modifiability, availability, performance, and testability, to illustrate how simple it is to tailor such questionnaires for your own use.
B.1 Using the Questionnaires
These questionnaires could be used by an analyst, who poses each question, in turn, to the architect and records the responses, as a means of conducting a lightweight architecture review. Alternatively, the questionnaires could be employed as a set of reflective questions, that you could, on your own, use to examine your architecture.
In either case, to use these questionnaires, simply follow these four steps:
1. For each tactics question, fill the “Supported” column with Y if the tactic is supported in the architecture and with N otherwise. The tactic name in the “Tactics Question” column appears in bold.
2. If the answer in the “Supported” column is Y, then in the “Design Decisions and Location” column describe the specific design decisions made to support the tactic and enumerate where these decisions are manifested (located) in the architecture. For example, indicate which code modules, frameworks, or packages implement this tactic.
3. In the “Risk” column, indicate the anticipated/experienced difficulty or risk of implementing the tactic using a (H = high, M = medium, L = low) scale. For example, a tactic that was of medium difficulty or risk to implement (or which is anticipated to be of medium difficulty, if it has not yet been implemented) would be labeled M.
4. In the “Rationale” column, describe the rationale for the design decisions made (including a decision to not use this tactic). Briefly explain the implications of this decision. For example, you might explain the rationale and implications of the decision in terms of the effort on cost, schedule, evolution, and so forth.
B.2 Availability
B.3 Interoperability
B.10 Further Reading
The tactics catalog from which the questionnaires are derived can be found in L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice (3rd ed.), 2012.
An analysis of quality attribute data from SEI ATAMs, showing which qualities are the most common in practice, can be found in I. Ozkaya, L. Bass, R. Sangwan, and R. Nord, “Making Practical Use of Quality Attribute Information”, IEEE Software, March/April 2008, and in a later study by S. Bellomo, I. Gorton, and R. Kazman, “Insights from 15 Years of ATAM Data: Towards Agile Architecture”, IEEE Software, 32:5, 38-45, September/October 2015.
The set of DevOps tactics was developed and presented in H-M Chen, R. Kazman, S. Haziyev, V. Kropov, and D. Chtchourov, “Architectural Support for DevOps in a Neo-Metropolis BDaaS Platform”, IEEE 34th Symposium on Reliable Distributed Systems Workshop (SRDSW), Montreal, Canada, September 2015.