QualityModels

1. Quality Models and
Quality Attributes

2. 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.

3. 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.

4. 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?

5. 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

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. Quality Requirements and
Architectural Design (Cont’d)
 Not all quality attributes are addressed
by the architectural design.
 Usability and performance both have
nonarchitectural aspects.

13. 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).

14. 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.

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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
 Identifies six quality characteristics –
functionality, reliability, usability, efficiency,
maintainability, and portability. These are
further divided into several subcharacteristics

21. 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.

22. Quality Metamodel
Observable
Via Execution
Not Observable
Via Execution
External Characteristic
Internal Quality Attribute
name
value
Metric
scale
method
1
1…* manifestation of
1 measure
1…*
Scenario
Engineering
Practice
addresses
1…* 1…*
Architecting
Practice

23. 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

24. The McCall/GE Model Factors
(Cont’d)
 Product revision factors
 Maintainability
 Flexibility
 Testability
 Product transition factors
 Interface facility
 Reusability
 Transferability

25. Additional Factors from Boehm
 Validity
 Clarity
 Understandability
 Modifiability
 Modularity
 Generality
 Economy
 Resilience
 Documentation

26. DeGrace and Stahl – Software
Engineering Practices
 Coding practices
 Management practices
 Use of design heuristics

27. 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

28. 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

29. 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

30. 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

31. 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

32. Bass, Clements, and Kazman
Categories for Quality Attributes
(Cont’d)
 The following are not observed by
executing the system:
 Modifiability
 Portability
 Reusability
 Integrability
 Testability

33. 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

34. 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.

35. The ISO/IEC 9126 Standard
 The six characteristics are:
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability

36. 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

37. 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.

38. 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

39. 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

40. 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.

41. 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.-

42. 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.

43. 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.

44. Modifiability
 It is the ability to grow an architecture
over time.
 A modifiable architecture can have new
features added without requiring
architectural rework

45. 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.

46. 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.

47. 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.

48. 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

49. 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.

50. 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.)

51. 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.

52. 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.

53. 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