Quality Models and
Quality Attributes
Outline
 Process and product quality
 Improving the quality of the process can improve the
quality of the product.
 Process quality does not address all qualities.
 Specifying quality requirements
 Some quality attributes can be quantifiably measured,
others have qualitative values which are observed.
 Understanding quality models
 A quality model is a taxonomy of quality attributes and
their relationships.
 Architecting with quality attributes
 Several quality attributes are influenced by the
architecture.
Process and Product Quality
 Process qualities are a measure of an
activity the end result of which is a product.
 Few quality models for the software
architecting process exist.
 Product quality is a measure of a tangible
product itself which could be the final
executable system or intermediate products
like specifications, models, plans, etc,
which collectively form the architectural
description.
Specifying Quality
Requirements
 Sample questions to discover
information about quality attributes:



How does the application fit into the
enterprise’s objectives, processes, and
other information systems?
How does it relate to other systems
including manual business processes?
Is it intuitive and usable or does it sit in a
virtual corner collecting cyber-dust?
Specifying Quality
Requirements (Cont’d)
 A quality attribute is a property of a
process or product that can have some
qualitative or quantitative value and can
be measured or observed.
 Examples of quality attributes are:




Maintainability
Portability
Functionality
usability
Specifying Quality
Requirements (Cont’d)
 A quality requirement is a specification of
the acceptable values of a quality
attribute that must be present in the
system.
 By leaving certain attributes out of the
requirements specification, it implies that
these attributes are not important.
 However, they were probably omitted
due to lack of understanding of the
quality or how to specify it.
Specifying Quality
Requirements (Cont’d)
 The external view of an application’s qualities is
called its characteristics (usability, performance,
etc.).
 Internal characteristics or subcharacteristics are
quality attributes viewable by the developers
(throughput, load balancing, fault tolerance, etc.).
 One internal attribute may influence one or more
characteristics.
 One characteristic may be influenced by one or
more internal attributes.
Measuring Quality Attributes
 A metric is a qualitative or quantitative
measurement or scale or a specified quality
attribute together with a method or technique
for observing or measuring the quality.
 Examples of internal metrics are the complexity
of the code logic, or the performance of specific
functions.
 The most common external metrics are tests of
the system’s functions, reliability, and
performance.
Measuring Quality Attributes
(Cont’d)
 Quality metrics should be specified as
unambiguously as possible.
 Qualities may be specified with
scenarios specified by the software
designers and architects with assistance
form the acquirers and users.
Quality Requirements and
Architectural Design
 Quality measurements are performed
primarily on the architectural description.
 While some measurements are
quantitative, most are qualitative.
 Qualitative evaluations, while not as
rigorous as quantitative evaluations, can
be objective and provide useful
predictions about he success of the
system in meeting quality requirements.
Quality Requirements and
Architectural Design (Cont’d)
 Quality attributes can be addressed
through architectural styles and patterns.
 Different architectural styles address
different sets of quality attributes and to
varying degrees.
 The specification of quality attributes,
therefore affects the architectural style of
the system.
Quality Requirements and
Architectural Design (Cont’d)
 Not all quality attributes are addressed
by the architectural design.
 Usability and performance both have
nonarchitectural aspects.
Systems Knowledge and
Quality Attributes
 In terms of levels of systems knowledge,
the identification of quality attributes is
equivalent to the source level (level 0) of
systems knowledge.
 Quality requirements are specific values
or ranges of values for these attributes
which is data level knowledge about the
system (level 1).
Systems Knowledge and
Quality Attributes (Cont’d)
 Software architecting begins with
creating models (generative level of
systems knowledge, or level 2) that can
generate the data level knowledge.
 We evaluate the architecture to see if it
indeed produces the same data as
specified in level 1.
Barriers to Achieving Quality
 Common reasons for failure to meet high
levels of quality include:



Misunderstanding of the importance of
quality attributes
Inadequate languages for expressing and
specifying quality requirements
Inadequate modeling methods and
notations for expressing solutions that
address specific quality attributes
Barriers to Achieving Quality
(Cont’d)
 Common reasons for failure to meet high
levels of quality include (cont’d):



Difficulty in designing for quality attributes
Lack of documented design and
architecture patterns for addressing quality
attributes
Quality control as an afterthought in most
projects
Common Quality Attribute
Misunderstandings
 Specifying Quality Requirements

There has been little work in the field of formal
specification for nonfunctional requirements
 Modeling Methods Don’t Address Quality
Attributes

Design methodologies are weak in representing
nonfunctional requirements
 Designing for Quality Attributes

Quality attributes are interdependent and cannot be
achieved in isolation
Common Quality Attribute
Misunderstandings (Cont’d)
 Solution Catalogues and Quality Attributes


Design patterns can be used to address some
quality attributes, but mapping them to a design
pattern’s context and problem statements is not
easy.
It may be worthwhile to begin cataloguing patterns
with respect to standardized quality attributes
 Quality Control is an Afterthought

Putting testing off until the end of the project is
effectively a statement that quality is not important
enough to be assessed early
Understanding Quality Models
 A quality model is a specification of the
required characteristics that a software
system must exhibit.
 Several quality models have been
developed over the years.

McCall/GE Quality Model
 Organizes
quality around three uses of
software: product revision, product
operations, and product transition
Understanding Quality Models
(Cont’d)
 Several quality models have been
developed over the years. (Cont’d)

Boehm Quality Model
 Shares
a common subset with the McCall
model and identifies additional quality
attributes

ISO/IEC 9126-1:2001 Quality Standard
six quality characteristics –
functionality, reliability, usability, efficiency,
maintainability, and portability. These are
further divided into several subcharacteristics
 Identifies
Understanding Quality Models
(Cont’d)
 Recent work at the SEI at CMU has produced a
framework for specifying quality models by
adding more precision to quality attribute
definitions and introducing metrics and analysis
techniques for measuring software and
architecture descriptions.
 Most development organizations do not employ
formal metrics for nonfunctional requirements.
They rely on testing, inspections and subjective
assessments of quality.
 If done right, these methods can be an effective
way of predicting system quality.
Quality Metamodel
Observable
Via Execution
Not Observable
Via Execution
External Characteristic
1
1…*
manifestation of
Internal Quality Attribute
name
value
1
addresses
1…*
1…*
Engineering
Practice
measure
1…*
Metric
scale
method
Scenario
Architecting
Practice
The McCall/GE Model Factors
 Factors (characteristics) describe the
external view of the software as viewed
by users of the application.
 Product operation factors





Accuracy
Reliability
Efficiency
Integrity
Usability
The McCall/GE Model Factors
(Cont’d)
 Product revision factors



Maintainability
Flexibility
Testability
 Product transition factors



Interface facility
Reusability
Transferability
Additional Factors from Boehm
 Validity
 Clarity
 Understandability
 Modifiability
 Modularity
 Generality
 Economy
 Resilience
 Documentation
DeGrace and Stahl – Software
Engineering Practices
 Coding practices
 Management practices
 Use of design heuristics
Laurence Best’s Application
Architecture
 One of the first attempts at applying
quality characteristics to architecture
 Previously models did not focus on
architecture but rather the entire process
and product of software engineering
 Best’s characteristics


Accuracy and comprehensiveness
Simplicity of use
Laurence Best’s Application
Architecture (Cont’d)
 Best’s characteristics (cont’d)





Operational flexibility
Ease of development, maintenance, and
extension
Security and control
Resource efficiency
Recovery
Bass, Clements, and Kazman
Categories for Quality Attributes
 Observable via execution
 Not observable via exceution
 Each of these is divided into three
subcategories:



System attributes
Business qualities
Architecture description qualities
Bass, Clements, and Kazman
Categories for Quality Attributes
(Cont’d)
 Observable via execution
 Not observable via execution
 The following attributes may be
observed by executing the system;





Performance
Security
Availability
Functionality
Usability
Bass, Clements, and Kazman
Categories for Quality Attributes
(Cont’d)
 Usability is composed of six quality
attributes:






Learnability
Efficiency
Memorability
Error avoidance
Error handling
Satisfaction
Bass, Clements, and Kazman
Categories for Quality Attributes
(Cont’d)
 The following are not observed by
executing the system:





Modifiability
Portability
Reusability
Integrability
Testability
Bass, Clements, and Kazman
Categories for Quality Attributes
(Cont’d)
 Some quality attributes are business
related:





Time to market
Cost
Targeted market
Rollout schedule
Extensive use of legacy systems
Bass, Clements, and Kazman
Categories for Quality Attributes
(Cont’d)
 In the SEI quality model, quality attributes have
three characterizations:



External stimuli,
Architectural decisions
Responses
 The requirements need to be specified in such a
way as to be observable.
 For example, maintainability should be specified as
concrete change scenarios that a software
developer would do to modify the system.
The ISO/IEC 9126 Standard
 The six characteristics are:






Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
Benefits of Quality Models
 The ISO/IEC 9126 identifies the
following uses of a quality model:





Validate the completeness of a
requirements definition
Identify software requirements
Identify software design objectives
Identify software testing objectives
Identify user acceptance criteria for a
completed software product
Benefits of Quality Models
(Cont’d)
 A quality model that defines quality
attributes precisely improves
communications between acquirers,
architects, and developers.
 A quality model that specifies usable and
practical metrics can improve the quality
of design models.
 Effective application of a quality model
adds more quality control earlier in the
project’s life cycle.
Architecting with Quality
Attributes
 The quality attributes that can be
addressed by an application’s
architecture are:






Functionality
Performance (efficiency)
Modifiability
Availability and reliability
Usability
Portability
Functionality
 It is the ability of the system or application
to satisfy the purpose for which it was
designed.
 It is related to validity, correctness,
interoperability, and security.
 It drives the initial decomposition of the
system.
 It is the basis upon which all other quality
attributes are specified
Interoperability
 It is the quality of a system that enables
it to work with other systems.
 It includes the quality to work with other
systems not yet known.
Security
 It is the ability to enforce authorization,
authentication, and deliberate denial of
service attacks.
 Security requirements can affect the
functional decomposition of the system.-
Performance (Efficiency)
 It represents the responsiveness of the system
(e.g., the time required to respond to events or
the number of events processed in some period
of time).
 Some aspects of performance are architectural
(the distribution of computations across
components) and some are not (choices of
algorithms).
 Performance has been a driving factor in
systems architecture and often compromises
the achievement of other quality attributes.
Resource Efficiency
 One aspect of performance is the
efficient utilization of resources.
 The decomposition of a system into
layers may impede the system’s ability to
satisfy performance requirements.
Modifiability
 It is the ability to grow an architecture
over time.
 A modifiable architecture can have new
features added without requiring
architectural rework
Availability and Reliability
 Availability is an attribute that measures
the proportion of time the system is up
and running.
 Reliability is an attribute that measures
the system’s ability to continue operating
over time.
 Both are partially addressed by the
architecture.
Recoverability
 It is the ability of a system to pick up
where it left off after a shutdown or
crash.
 This might involve launching diagnostic
programs to check the integrity of the
system before the actual system
launches.
Usability
 This typically refers to the usability with
respect to the end user.
 It can also address other system users
such as system maintainers, operators,
etc.
 It is measured using scenarios.
Portability
 It is the ability to reuse a component in a
different application or operating environment.
 It can be considered as a special kind of
modifiability.
 Portability related attributes are:




Adaptability
Installability
Conformance
Replaceability
Portability (Cont’d)
 Extensibility is another word for
portability.
 One way to satisfy the extensibility
requirement is to produce a set of
platform-independent architectural
models. This forces the designer to
consider the architecture from a
platform-independent point of view.
Architecting and Quality
Models
 The architectural practices used to address
quality attributes include the use of patterns and
heuristics.
 Architectural styles are high-level architecture
patterns that address a specific set of concerns
or quality attributes.
 Some views (and models) address particular
quality attributes and not others. (E.g., use
cases address functionality but not
performance.)
Architecting and Quality
Models (Cont’d)
 Some quality attributes cannot be
entirely evaluated by inspecting the
models alone; some require additional
context information such as scenarios.
(E.g., modifiability can not be address
without specifying what is to be
modified.) A set of modification
scenarios must be supplied.
Summary
 Quality attributes are measurable or
observable characteristics of products
and processes.
 The quality requirements specification
gives quantitative or qualitative values
for these attributes that must be satisfied
by the executable system.
 It is cost effective to evaluate models
and other intermediate products with
respect to quality attributes.
Summary (Cont’d)
 Not all quality attributes can be satisfied by
architectural decisions.
 Reasons why the use of quality attributes is not
common.







Misunderstanding of their importance
Inadequate languages for expressing them
Inadequate specification of quality requirements in projects
Inadequate modeling methods and notations
Inherent difficulty in designing for quality attributes
Lack of documented design and architectural patterns
The fact that quality control is an afterthought on most
projects