Quality Attributes

Lots of questions??

What does it mean if we say we want a system to be portable or secure? Are things like performance really an entirely different sort of requirement to making the system provide specific business etc related functionality? Doesn't the architecture of a chosen system make it either more or less likely they will meet these requirements?

In the Bass, Clements and Cazman book Software Architecture In Practice, they define the concept of qualityAttributes. These are cover all aspect of quality both functional and what often gets called non-functional (NonFunctionalIsNonsense).

The question for me at the moment is - can we make a mapping between QualityAttributes and ArchitecturalPatterns or may be ArchitecturalStyle? I want to be able to have something that captures the knowledge that there is a tradeoff between the various quality attributes and to have some receipies that tell me that if I want this mix of quality attributes, I could try this architectural pattern(s).

So what does anybody think??

I take the tradeoff referred to above to be between "quality" and price. I believe that over the normal range of quality, there is not in fact a tradeoff. It does not really cost more to get acceptable performance, it does not really cost more to get acceptable reliability.

On the contrary, aggressive ongoing testing practices, built into the overall process, reduce cost by increasing development speed, while ensuring the level of quality you want.

Performance, over the normally-required range, works the same way. Selection of a reasonable architecture, followed by orderly implementation of the system and its tests, followed by measurement and optimization of the working system, will generally result in acceptable performance at a quite reasonable cost.

See UnitTest, FunctionalTest, WorstThingsFirst, CostReliabilityTradeoff. --RonJeffries

Actually, what I was really talking about was the more general trade off between different QualityAttributes (of which one might be "cost" (or something very like it) and another might be reliability (which is related to reducing the number of bugs).

The other sorts of trades of which are of interest are things like performance vs security, portability vs performance (you often add layers to give greater portability but this probably slows down the execution).

Not all QualityAttributes are likely to be influenced by ArchitecturalPatterns but some are. -AndyMoorley

The classic trade-off is time versus space. Eg you can often make something faster by adding a (memory hungry) cache. -- DaveHarris

Someone at the top asked for patterns which relate to architectural quality attributes. Come on down to MicroArchitecture and see if it looks right. --RichardHenderson.

For more detailed information on QualityAttributes and SoftwareArchitecture see AttributeBasedArchitecturalStyles and ArchitectureTradeoffAnalysisMethod. -- RobertDiFalco

Functionality, extensibility and reliability are important attributes for architecture and design.

All of these can be viewed as direct corresponding with *representation*, which should be sufficient, and *complexity*, which should be minimized. Extensibility can then be considered as identifying likely areas for future development. --ThomasWhitmore

http://www.sce-tech.com

QualityAttributes amusingly and concisely defined as established *fact* (qualified as "the definition that's stood the longest test of time ... pretty generally accepted ... for almost 30-something years"), from Robert L. Glass, Facts and Fallacies ofSoftware Engineering (Addison-Wesley, 2002). ISBN 0321117425

"Fact 46: Quality is a collection of attributes.

1. Portability is about creating a software product that is easily moved to another platform.

2. Reliability is about a software product that does what its supposed to do, dependably.

3. Efficiency is about a software product that economizes on both running time and space consumption.

4. Human engineering (also known as usability) is about a software product that is easy and comfortable to use.

5. Testability is about a software product that is easy to test.

6. Understandability is about a software product that is easy for a maintainer to comprehend.

7. Modifiability is about a software product that is easy for a maintainer to change." -- pp. 129-130

Note that his notion of efficiency (attribute #3 above) conflates time and space, long recognized as a classic software tradeoff.

Glass notes that these attributes are not listed in any particular order. Relative priorities will differ by project and he considers it essential to prioritize all the above attributes for each project. (He does not attempt any mapping of such QualityAttributes priority rankings to any particular DesignPatterns, ArchitecturalPatterns or AttributeBasedArchitecturalStyles.)

Glass also defines QualityAttributes negatively (and somewhat incoherently in light of the above):

"Fact 47: Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability." -- p. 132

Taking his two facts together, it appears Quality resides in a software product, beyond all reach of such mundane concerns as whether or not it can be made at all. Money and time and the relationship of software to human purposes can mean but little to the essence of software Quality.

One is left to wonder how else but some metric for "user satisfaction" to decide between "a software product that is easy and comfortable to use" and one not so usable or human engineered (quality attribute #4, asserted in Fact 46). Further, "reliability" is the very name for Glass's second listed attribute of quality software, a plain contradiction. Either he is equivocating from page to page or he is deeply confused about the relationship of attributes and definitions, if not software quality, an exercise I'll leave to the reader. Chapter 3, "About Quality", is freely browsable online. Begin at the beginning, with the author's revealing reference to "that wonderful book", Zen and the Art of Motorcycle Maintenance: "the main character in the book, an academic looking into the real meaning of the word [Quality], went mad seeking a workable definition!" -- p. 127. -- PaulWilson

CategoryQuality