Quality%20Models%20and%20Quality%20Attributes - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Quality%20Models%20and%20Quality%20Attributes

Description:

Improving the quality of the process can improve the quality of the product. ... Not observable via exceution. Each of these is divided into three subcategories: ... – PowerPoint PPT presentation

Number of Views:110
Avg rating:3.0/5.0
Slides: 54
Provided by: robertw8
Learn more at: http://www.ecs.csun.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Quality%20Models%20and%20Quality%20Attributes


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
    enterprises 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 (Contd)
  • 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 (Contd)
  • 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 (Contd)
  • The external view of an applications 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
    systems functions, reliability, and performance.

9
Measuring Quality Attributes (Contd)
  • 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
(Contd)
  • 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
(Contd)
  • 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 (Contd)
  • 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 (Contd)
  • Common reasons for failure to meet high levels of
    quality include (contd)
  • 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 Dont 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
(Contd)
  • Solution Catalogues and Quality Attributes
  • Design patterns can be used to address some
    quality attributes, but mapping them to a design
    patterns 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 (Contd)
  • Several quality models have been developed over
    the years. (Contd)
  • Boehm Quality Model
  • Shares a common subset with the McCall model and
    identifies additional quality attributes
  • ISO/IEC 9126-12001 Quality Standard
  • Identifies six quality characteristics
    functionality, reliability, usability,
    efficiency, maintainability, and portability.
    These are further divided into several
    subcharacteristics

21
Understanding Quality Models (Contd)
  • 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
External Characteristic
Observable Via Execution
1
1
manifestation of
Internal Quality Attribute name value
Not Observable Via Execution
Engineering Practice
addresses 1 1
1 measure
1
Architecting Practice
Metric scale method
Scenario
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 (Contd)
  • 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 Bests 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
  • Bests characteristics
  • Accuracy and comprehensiveness
  • Simplicity of use

28
Laurence Bests Application Architecture (Contd)
  • Bests characteristics (contd)
  • 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 (Contd)
  • 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 (Contd)
  • Usability is composed of six quality attributes
  • Learnability
  • Efficiency
  • Memorability
  • Error avoidance
  • Error handling
  • Satisfaction

32
Bass, Clements, and Kazman Categories for Quality
Attributes (Contd)
  • The following are not observed by executing the
    system
  • Modifiability
  • Portability
  • Reusability
  • Integrability
  • Testability

33
Bass, Clements, and Kazman Categories for Quality
Attributes (Contd)
  • 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 (Contd)
  • 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 (Contd)
  • 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 projects
    life cycle.

38
Architecting with Quality Attributes
  • The quality attributes that can be addressed by
    an applications 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 systems 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 systems 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 (Contd)
  • 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 (Contd)
  • 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 (Contd)
  • 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
About PowerShow.com