Quality models and quality attributes
Download
1 / 53

quality models and quality attributes - PowerPoint PPT Presentation


  • 478 Views
  • Updated On :

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'quality models and quality attributes' - paul


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Outline l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 d6 l.jpg
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 d7 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 d12 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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


Understanding quality models cont d21 l.jpg
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 l.jpg
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


The mccall ge model factors l.jpg
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 l.jpg
The McCall/GE Model Factors (Cont’d)

  • Product revision factors

    • Maintainability

    • Flexibility

    • Testability

  • Product transition factors

    • Interface facility

    • Reusability

    • Transferability


Additional factors from boehm l.jpg
Additional Factors from Boehm

  • Validity

  • Clarity

  • Understandability

  • Modifiability

  • Modularity

  • Generality

  • Economy

  • Resilience

  • Documentation


Degrace and stahl software engineering practices l.jpg
DeGrace and Stahl – Software Engineering Practices

  • Coding practices

  • Management practices

  • Use of design heuristics


Laurence best s application architecture l.jpg
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 l.jpg
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 l.jpg
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 l.jpg
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 d31 l.jpg
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 d32 l.jpg
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 d33 l.jpg
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 d34 l.jpg
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 l.jpg
The ISO/IEC 9126 Standard (Cont’d)

  • The six characteristics are:

    • Functionality

    • Reliability

    • Usability

    • Efficiency

    • Maintainability

    • Portability


Benefits of quality models l.jpg
Benefits of Quality Models (Cont’d)

  • 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 l.jpg
Benefits of Quality Models (Cont’d) (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 l.jpg
Architecting with Quality Attributes (Cont’d)

  • The quality attributes that can be addressed by an application’s architecture are:

    • Functionality

    • Performance (efficiency)

    • Modifiability

    • Availability and reliability

    • Usability

    • Portability


Functionality l.jpg
Functionality (Cont’d)

  • 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 l.jpg
Interoperability (Cont’d)

  • 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 l.jpg
Security (Cont’d)

  • 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 l.jpg
Performance (Efficiency) (Cont’d)

  • 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 l.jpg
Resource Efficiency (Cont’d)

  • 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 l.jpg
Modifiability (Cont’d)

  • 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 l.jpg
Availability and Reliability (Cont’d)

  • 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 l.jpg
Recoverability (Cont’d)

  • 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 l.jpg
Usability (Cont’d)

  • 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 l.jpg
Portability (Cont’d)

  • 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 l.jpg
Portability (Cont’d) (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 l.jpg
Architecting and Quality Models (Cont’d)

  • 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 l.jpg
Architecting and Quality Models (Cont’d) (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 l.jpg
Summary (Cont’d)

  • 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 l.jpg
Summary (Cont’d) (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


ad